DETAILED ACTION
Notices to Applicant
This communication is a final rejection. Claims 97-118, 120-122, 124-126, 128-129, 131-146, 150-172, as filed 08/26/2026, are currently pending and have been considered below.
Priority is generally acknowledged as shown on the filing receipt with the earliest filing date being 02/26/2019.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 97-99, 105, 108-109, 111-113, 117-118, 124-126, and 128 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Specifically, each of these claims was amended to depend from claim 151 which lacks a shared display configuration, a configuration store, determined first data, selected first data, a step of determining that patient records correspond to the same subject patient, or a step of resolving an identify of the same patient.
Claims 99, 105, 108, 109, 111, 117, 125, and 128 recite “the shared display configuration.
Claim 126 recites “the shared display configuration” and “the configuration store”.
Claims 113 and 124 recite “the determined first data”.
Claims 117 and recite “the selected first data”.
Claims 97 and 112 recite “determining that a first patient record…and a second patient record…correspond to the same subject patient”.
Claims 98 and 124 recite “resolving an identity of the same subject patient.
None of these terms has antecedent basis in claim 151, thus the scope of the claims is not reasonably ascertainable. Applicant says as much on page 43 of the 8/26/2026 Remarks: “[c]laim 151 recites no shared display configuration…”
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.
5. Claims 97-118, 120-122, 124-126, 128-129, 131-146, and 150-172 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Although the claims fall within a statutory category, they are directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1
The claims recite subject matter within a statutory category as a process, machine, and/or article of manufacture.
Claim 151 is exemplary. Claims 129, 158, and 166 are addressed separately below.
Step 2A Prong One
Claim 151 recites abstract ideas, namely, mental processes. But for recitation of generic computer components such as a “medical record dashboard system,” a “weighting module,” and a “trigger processing module configured as a rules engine,” the below features amount to abstract ideas.
Claim 151 recites evaluating each of a patient’s clinical events by assigning it a rating based on the event’s type and content, raising or lowering that rating because of another clinical event in the patient’s history, adjusting it again for the time of the event, and adjusting it once more for the level of detail at which the record is being viewed, and then deciding from the resulting values which events to place first, which to emphasize, which to leave out, and which to flag. These are steps a clinician performs mentally or with pen and paper when reviewing a chart: a physician forms an initial sense of how significant a finding is, revises that sense in light of a related finding elsewhere in the history, discounts it because it is old, and settles on what matters at the level of detail he is reviewing. Nothing in the claim precludes these determinations from practically being performed in the mind. See MPEP 2106.04(a)(2)(III)(C).
Reciting four separately named values for the successive stages of that judgment does not change the analysis. Naming the intermediate products of a mental evaluation does not remove the evaluation from the mental processes grouping.
The “zoom level” of limitation (d) does not alter this result. The specification in [0351] (as published) describes this feature as follows: At its highest zoom level, only the most important factors are displayed. And its lowest zoom level, flowsheet-level access can be achieved. At each zoom interval, reprocessing of rules can occur to include additional data, differing representations of data, and notifications of key events. Weighing which events matter at a one-year view of a record and which matter at a ten-year view is the same act of summarizing a history at a chosen scope.
Dependent claims further narrow or define the abstract idea. For example, claims 152-155 and 159-161 recite the data formats and contextual inputs used in the evaluation, and claims 97-99, 112, and 128 recite particular aspects of how patient records are compared and scored.
Step 2A Prong Two
This judicial exception is not integrated into a practical application, because the additional elements:
amount to mere instructions to apply an exception. For example, the “one or more processors,” the “memory storing instructions,” the “weighting module,” and the “trigger processing module configured as a rules engine” amount to invoking computers as a tool to perform the abstract idea, applicant’s specification reciting no more than “a computing device comprising at least one processor, a non-transitory computer-readable medium, having stored thereon, software instructions” (see applicant’s specification [0027] as published) (see MPEP 2106.05(f)).
add insignificant extra-solution activity to the abstract idea. For example, receiving the first data and the second data amounts to mere data gathering, and generating the display state amounts to presenting the result of the evaluation (see MPEP 2106.05(g)).
Claim 151 does not recite a mechanism by which the operation of the recited display system, database, or rules engine is itself improved. Instead the claim recites ranking logic and output of a display. Applicant’s specification describes the technical problem as presenting multi-source data in a single interface “without unacceptable delay” (specification [0009] (as published)); the recited ratings do not address that problem, and no change to the operation of the display or the underlying databases is claimed. Additionally, to the extent that the logic of the claim reduces delay, the result flows from the abstract idea itself. That is, improving the logic that is used to summarize a record is an improvement to a mental process, not to a technology.
Dependent claims add only subject matter consistent with the additional elements in the independent claims. For example, claims 100, 108, 110, 113, 131, 144, and 169 recite data transmission and interoperability formats which amount to invoking computers as a tool to perform the abstract idea. Viewed as an ordered combination, the limitations add nothing beyond the elements taken individually. Nothing indicates that the combination improves the functioning of a computer or any other technology. Collectively the elements provide a conventional computer implementation and do not meaningfully limit the abstract idea.
Claims 129, 158, and 166
Claim 158 recites the same evaluation as claim 151 and is directed to the same mental process. Claim 158 does not recite the zoom-level stage, the display state, or the updating step of claim 151.
Claim 166 recites determining a subset of a patient’s information to share with a second provider, recording that choice, giving the second provider access to it, and assembling the two providers’ information into one view arranged by encounter. These are steps in the management of interactions between medical care providers so that they may co-manage a patient, which are certain methods of organizing human activity, and they are also steps a person performs mentally or with pen and paper in deciding what to send a consulting physician and in reading two charts side by side. The additional elements are the recited dashboard system, processors and non-transitory media, which amount to instructions to apply the exception with a computer (see MPEP 2106.05(f)).
The recitation in claim 166 that values are displayed “without requiring migration of patient-related data ... to a common patient chart or a common patient database” states where data is not stored. It is a negative constraint on generic data access and does not amount to an improvement in any technology (see MPEP 2106.05(f) and (h)).
Claim 129 recites the same subject matter as claim 166 in system form, together with a data integration layer, a patient-matching module, a personal health record display, and a trigger processing module. Each is recited functionally, at the level of a result to be achieved rather than a mechanism, and each amounts to invoking computers as a tool to perform the abstract idea. The clause added by the 08/26/2026 amendment, reciting that the trigger processing module applies the sharing rules “at rendering time ... to determine a display state of individual data elements,” states when a determination is made, not a mechanism by which the system’s operation is improved.
Step 2B
The claims do not include additional elements sufficient to amount to significantly more than the judicial exception. As discussed under Step 2A Prong Two, the additional elements amount to no more than mere instructions to apply an exception and add insignificant extra-solution activity to the abstract idea. Additionally, the limitations beyond the abstract idea itself have been recognized as well-understood, routine, and conventional activity in particular fields such as receiving or transmitting data over a network (Symantec, MPEP 2106.05(d)(II)(i)), electronic recordkeeping (Alice Corp., MPEP 2106.05(d)(II)(iii)), and storing and retrieving information in memory (Versata Dev. Group, MPEP 2106.05(d)(II)(iv)).
Claim Rejections - 35 USC § 103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
6. Claims 166-169 and 171 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1).
Ginsburg discloses a data command center visual display system that draws patient information from multiple providers’ electronic medical record systems into configurable display panels and a patient flowsheet. Ginsburg discloses a computing system with processors and network and application interfaces (“the system 30 can include at least one computing device, including one or more processors 32 ... a network interface 35 a and an application interface 35 b,” [0217]);
--interfaces to the providers’ EMR systems ([0146]; [0153]);
--a flowsheet that “integrates the patient medical history information into a table that presents the patient’s medical history by visit to at least one physician with respective procedures or actions performed during each visit represented as first icons identifying the procedure or action performed and second icons enabling selection of a new procedure or action,” [0021];
--a flowsheet “adapted to include medical history information from more than one medical provider in order to provide shared treatment of the patient in the patient flowsheet,” [0034];
--user selection of the data to be displayed (“The user then selects data to populate the panel from the Data Selector 3442,” [0290]) and saving of the resulting view (“the user may save (3428) or cancel (3430) their actions,” [0289]);
--storage of the view as configuration data (“XML code moves and stores different display panel and flowsheet views ... a panel ID that links the panel to a tab, the panel’s position,” [0032]; [0219]; “All user entered data is always stored on the central server 5000 first,” [0298]);
--grant of access to a second user (“a user 31 can grant access to at least one other user of the command center visual display system and method ... shared access can be restricted to viewing at least a portion of the shared patient’s account or record,” [0223]; co-management in [0240]-[0241]);
--an application deployed separately from the providers’ own record systems (“The Command Center architecture 5000 is a multi-tenant cloud-based web application ... multi-tenant means that the application is deployed once and all customers access the same server. Data is segregated by the application so that customers can only access their own data,” [0292]);
--a rules engine (“the visual display system provides access to a clinical decision support system that uses a rules engine and/or natural language processing,” [0025]);
--alerting within the panel (“an alert icon is provided in an adjustable display panel and/or the patient flowsheet that, when selected by the user of the visual data system, opens an alert message without leaving the display screen,” [0026]);
--status indicators that change with the record (“diagnosis indicators providing a visual representation of an improvement of a medical problem ... or a worsening,” [0029]; change in color and icons in [0172]);
--update on new data (“data input by the user of the visual display system may trigger auto-population of information in the adjustable display panels and patient flowsheet,” [0028]); and standardized exchange interfaces (“IHE profiles, CDA and CCD, NwHIN Direct, HL7v2, HL7v3, DICOM, X12,” [0178]; FHIR in [0303]).
Dvorak discloses the exchange of clinical information among different record systems o, each of which continues to store its own patient data, using a clinical information exchange server that keeps only an index of where each event is held and that composes a listing of those events for display in response to a request. Dvorak discloses the need for “exchange of information between distinct healthcare organizations, whether operating similar or dissimilar computer systems, who are also called on from time to time to efficiently exchange information about patients who need treatment at other institutions,” [0004];
--separate systems resident on separate servers (“each separate application in the network is resident on a separate server,” [0018]) supplied by different vendors (“Often the different applications are from different vendors,” [0014]);
--the participating systems need not belong to one organization (“It is not important if the systems are all within a common healthcare enterprise, or if they are hosted by separate but cooperating enterprises,” [0027]);
--that the exchange server holds no clinical data (“The CIXSD does not, and is not intended, to store all of the information stored by each application system about the patient event. The CIXSD serves instead as a sort of pointer to direct any given application as to where to find information it may need to access in another application,” [0020]; “the event registry typically does not contain actual medical records data but contains instead identifiers that can be used to compose a query to the system maintaining data about the event,” [0014]);
--resolution of the patient’s identity across those systems by a master patient index (“This listing is referred to here as the Master Patient Index,” [0015]; “which assigns a system-unique identification code for each unique patient,” [0015]) and by a stored cross-reference of the identifiers each system uses (“a look-up table to facilitate easy look up of the various patient identification numbers or codes assigned by each of the software applications in the enterprise to that identify the same patient,” the table extending to “identification methods used by related organizations or remote medical practices with which the enterprise might, on occasion, share or cross-refer patients,” [0021]);
--an event listing organized by date and identifying the system holding each event (“the CIXSD will keep a listing of the type of event, the date of the event, the application system holding data about the event and an assigned unique event number,” [0022]); retrieval of the underlying data from the holding system when a displayed event is selected (“The nurse viewing this event listing may select an event, for example a hospital stay by the patient, and request an abstract of that event,” [0026]);
--composition of the displayed table at the time of the request by way of web query interfaces (“http://Epic700/CES/update.asp?access=elctrosolor&ID=845&audit=391488588&refNo=60285,” [0038]; “an HTML table is returned showing the requested events,” [0041]),
--the columns of which are “Column 1—Date—Date of event occurrence (required),” [0042], the type of the event, a description, other data which “may contain information such as the provider, the clinic, the reason for the visit or any similar data,” [0045], and “Column 5—ReportCode—A code with which a detail report on the event may be retrieved,” [0046]; a date-range parameter limiting what the query returns (“This number instructs this server to return events within the past specified dates,” [0035]); assembly of the returns from several systems into one displayed table (“The returned HTML page should not have <HTML> and <BODY> tags so that multiple returned pages can be concatenated together,” [0041]); and
--presentation of the assembled result to the user as though it were a single record (“The nurse can view the data through a conventional web browser,” [0026]; “The entire communication is invisible to the user and simple seems as if all the data is directly available to the nurse through his or her computer,” [0026]; “distinct and separate systems can share patient clinical data in a manner that seems seamless to the user,” [0017]), no participating system holding the others’ records (“each of the systems has access to the events stored by the others, yet no system needs to maintain the records or any interface information, about the other systems,” [0027]).
Regarding claim 166, Ginsburg discloses the recited computerized method executed by a medical records dashboard system of one or more processors and one or more non-transitory computer-readable media storing software instructions, for co-managing care of a same subject patient across a plurality of medical care providers by sharing selected portions of a medical record ([0217]; [0005]);
--generating a first display for a first medical care provider user comprising at least a first panel, window, or display region presenting patient-related information for one or more encounters of the same subject patient from that provider’s medical record databases and associated health information systems ([0021]; [0146]; [0153]);
--determining first data comprising a subset of the patient-related information in the first panel for sharing with a second user associated with a second medical care provider ([0290]; FIGs. 56A and 56B);
--creating a shared display configuration based on the determined first data, including one or more first parameters identifying the first data, display attributes of the first data, and one or more clinical parameters to be displayed ([0289]; [0032]);
--storing the shared display configuration in a configuration store in association with the same subject patient ([0298]; [0219]);
--providing access to the shared display configuration to the second user ([0223]; [0240]-[0241]); and
--generating, using the shared display configuration, a shared panel in a display of the second user including a combination of the first data and second data for the same subject patient from one or more medical record databases of the second medical care provider arranged by encounters of the same subject patient over time ([0034]; [0021]).
Ginsburg does not expressly disclose but Dvorak teaches:
--wherein the first medical care provider and the second medical care provider each independently maintain separate patient records for the same subject patient such that, without the shared display configuration, the patient-related information of the first medical care provider is not accessible to a display of the second user ([0018]; [0027]);
--wherein resolving an identity of the same subject patient across the medical record databases of the first and the second medical care provider is performed by a patient identification mechanism ([0015]; [0021]); and
--wherein values originating from the first medical care provider and values originating from the second medical care provider are retrievable and displayable in the shared panel, arranged by encounters of the same subject patient over time, without requiring migration of patient-related data to a common patient chart or a common patient database ([0020]; [0022]; [0041]; [0042]; [0026]).
Dvorak thus teaches the rendering of values originating from two separately maintained record systems into one displayed panel, and teaches it without migrating either system’s data: the exchange server holds no record data, [0014] and [0020], each participating system keeps its own records, [0027], and the panel is assembled from what the holding systems return in answer to the request, [0041].
One of ordinary skill in the art before the effective filing date would have been motivated to expand Ginsburg’s data command center to include the clinical information exchange of Dvorak because doing so would permit “the prompt sharing of critical patient information amongst the caregivers who might treat a particular patient” (Dvorak [0004]) among providers that continue to maintain their own separate records, so that “distinct and separate systems can share patient clinical data in a manner that seems seamless to the user” (Dvorak [0017]).
Dvorak’s event registry and query interfaces do not affect the normal functioning of Ginsburg’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
The remaining claims of this ground are rejected as set forth below.
Claim
Subject matter
Taught by
167
separately administered instances of the same or different vendor platform
Dvorak [0014]; [0027]
168
patient-matching criteria
Dvorak [0015]; [0021]
169
Data Access Point external to both databases; standardized exchange protocols
Ginsburg [0178]; [0303]; Dvorak [0017]; [0026]
171
values retrieved on demand at rendering time, without persistence to a common chart or database, each render reflecting current state
Dvorak [0020]; [0026]; [0038]; [0041]
7. Claims 129, 131-140, 142-144, 146, and 150 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1) and McNair (US20150193583A1).
The Ginsburg and Dvorak teachings, and the motivation to combine Dvorak with Ginsburg, are as set forth above. Claims 131-140, 142-144, 146, and 150 depend from claim 129 and include its rendering-time limitation.
McNair discloses record systems that “may use distinct clinical ontologies, nomenclatures, vocabularies, or encoding schemes for clinical information,” and that “in some embodiments EHRs 160, 162, and 164 are affiliated with two or more separate health care entities that use two or more distinct nomenclatures,” [0034];
--“near-real time querying across diverse health records data sources, which may use diverse clinical nomenclatures and ontologies,” [0006];
--that the determination is made at the time the chart is opened (“upon opening a patient chart, the chart application connects with embodiments of the decision support services, which may operate in the cloud, to see if there are any new risks for a clinical condition (including a decision support event) to manage for a particular patient or sets of patients,” [0028]; “when a user opens another patient’s chart, the application again uses the user’ role (e.g. caregiver specialty) and venue and the person’s (or patient’s) information in the cloud to see if there are new risks for conditions,” [0029]);
--that the determination governs the display state of the individual items shown (“the decision support patient chart includes functionality for flexing or altering the information that is displayed (including what information is presented and the order, ranking, or priority that the information is presented) based on the caregiver specialty, condition(s), venue, or other attributes,” [0029]; “a dynamic menu or table of contents (TOC) indicates the risk for one or more clinical conditions, and in some embodiments, a newly identified risk is highlighted or colored,” [0028]; “a caregiver may be notified of a newly identified risk by alarm, email or text message, icon, or other technique,” [0028]; “Upon selecting a risk of one or more conditions from the TOC, the user-caregiver is provided supporting details,” [0028]); and
--resolution of patient identity across the sources (“patient records from different data sources or systems are determined to have a probability of being records for the same patient, based on clinical and demographic attributes,” and are “matched using a record linkage algorithm or agent thereby generating an inner-operable longitudinal patient record,” [0093]).
Regarding claim 129, Ginsburg discloses the medical record dashboard system carrying out the method of claim 166 in system form ([0217]; [0021]; [0290]; [0289]; [0298]; [0223]; [0034]);
--a data integration layer configured to communicate with one or more medical record databases and associated health information systems of a first and a second medical care provider, the health information systems including at least one of an electronic medical record system, a practice-management system, a hospital information system, a health information exchange, a picture archive and communications system, a clearing house or billing system, or a laboratory system ([0146]; [0153]; [0178]);
--a trigger processing module forming part of the medical record dashboard subsystem, configured as a rules engine executing one or more computer-implemented sharing rules stored in the configuration store and logically separated from the medical record databases of both providers ([0025]; [0292], the application being separate from the providers’ own record systems interfaced at [0146] and [0153]); and
==a first interface configured to generate, for the same subject patient, a personal health record display organizing a patient medical history into a unified chronological view including at least one of scheduled and past appointments, current and historical medications, surgical and procedural history, active and historical diagnoses, and radiology and imaging appointments ([0021]; [0034]). The patient-matching module and the data access point are taught by Dvorak ([0015]; [0021]; [0038]; [0041]).
Ginsburg and Dvorak do not expressly disclose but McNair teaches:
--wherein the trigger processing module further updates the shared panel and the personal health record display by applying, at rendering time as new encounter data is received via the data integration layer, the one or more computer-implemented sharing rules stored in the configuration store to determine a display state of individual data elements rendered at the shared panel and at the personal health record display, such that a display state of each such data element is determined by the trigger processing module at rendering time based on current content of the one or more medical record databases accessible via the data integration layer ([0028]; [0029]; [0006]).
McNair applies its rules when the chart is opened, applies them to the data the sources hold at that time, and performs the determination “again” on each opening, [0029]. Dvorak likewise composes the displayed table in answer to the request that calls for it rather than in advance, [0038] and [0041].
One of ordinary skill in the art before the effective filing date would have been motivated to expand the shared panel of Ginsburg and Dvorak to include the chart-opening evaluation of McNair because doing so would “present the caregiver with information at just the right time, along with data that is relevant to the current context” (McNair [0027]).
McNair’s chart-opening evaluation does not affect the normal functioning of Ginsburg and Dvorak’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
The dependent claims of this ground are rejected as set forth below.
Claim
Subject matter
Taught by
131
standardized exchange interfaces; Data Access Point protocols
Ginsburg [0178]; [0303]; Dvorak [0026]
132
order input, order record, and scheduling-system update
Ginsburg [0022]; [0026]; [0028]
133
specialty-specific display configuration
Ginsburg [0024]; McNair [0029]
134
notification on an unconfirmed or missed appointment
Ginsburg [0068]; [0031]
135
monitoring for critical clinical events and routing notifications
Ginsburg [0025]; [0026]; McNair [0028]
136
hosted multi-tenant deployment with logically separated data
Ginsburg [0292]; [0058]
137
automatically determined data presented for review before storage
Ginsburg [0289]
138
clinical-relevance score from a machine-learning model
Ginsburg [0015]; McNair [0028]
139
notification that a shared panel is available
Ginsburg [0026]; McNair [0028]
140
look-back period limiting the data included
Dvorak [0035]
142
per-field source column, inclusion flag, and representation type
Ginsburg [0032]; Dvorak [0022]; [0045]
143
separately administered instances of the same or different vendor platform
Dvorak [0014]; [0027]
144
FHIR application programming interface
Ginsburg [0303]
146
indexing both providers’ records onto a shared encounter timeline
Ginsburg [0034]; [0021]; Dvorak [0022]
150
external context signal: coverage determination or coverage status
Ginsburg [0025]; [0031]
8. Claims 158-165 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1) and Cornelius (US10431339B1).
The Ginsburg and Dvorak teachings, and the motivation to combine Dvorak with Ginsburg, are as set forth above.
Cornelius discloses identifying which items of a patient’s historical record are relevant to the patient’s current condition and displaying them with graded prominence according to a computed relevance score. Cornelius discloses that the system “may treat some pieces of historical patient information as having a higher importance, independent of the current condition,” (col. 12 lines 55-58) so that “a very mild or long-past injury to the shoulder may be given less importance than a severe or recent injury to the thumb,” (col. 12 lines 58-61) and claims “determining the input value based on one or more of a severity and a recentness associated with the past diagnosis” (claim 9);
--that the score of one item is adjusted by reference to another, in that the system may “increase the weight between two conditions in response to determining that the conditions often occur in the same patients” (col. 15 lines 55-57) and, on a further diagnosis being received, performs “modifying the weighted graph to increase the second relevance score” (claim 6);
--that the weighting is adjusted for the passage of time, in that “the system may occasionally adjust the weights automatically as time passes” (col. 13 lines 18-20); that the weight is adjusted according to where the item came from, by “determining a source that established the past diagnosis of the patient; and automatically adjusting the weight between the past diagnosis and the current condition based on the source that established the past diagnosis of the patient” (claim 15);
--that a relevance score is arrived at by “using the weight and an input value to determine a relevance score of the past diagnosis to the current condition” (claim 1);
--that display is governed by the resulting score, by “determining a level of prominence with which to display the historical information based on the relevance score, wherein determining the level of prominence comprises comparing the relevance score to a plurality of thresholds, and wherein each threshold of the plurality of thresholds defines a different level of prominence for displaying the historical patient information” (claim 1); and
--that the scores are recomputed on change, by “detecting a change in relevance of the past diagnosis to the current condition; and responsively modifying the weighted graph to change the weight in accordance with the detected change in relevance” (claim 3) and
--“updating the relevance score based on the second input value and the weight” (claim 12).
Regarding claim 158, Ginsburg discloses the recited medical record dashboard system comprising one or more processors and a memory storing instructions ([0217]); receiving first data and second data associated with one or more encounters of a same subject patient from a first user and a second user ([0146]; [0153]; [0034]; [0223]); identifying, based on the first data and the second data, a plurality of clinical events associated with the same subject patient ([0021]); and generating a shared panel for a second display associated with the second user comprising an encounter-aligned view of at least the plurality of clinical events ([0021]; [0034]).
Ginsburg does not expressly disclose but Dvorak teaches: wherein the first user and the second user are associated with different provider systems and wherein the first data and the second data are maintained separately in their respective provider systems ([0018]; [0027]); and providing the second user with access to the shared panel via the second display, wherein values originating from the provider system of the first user and values originating from the provider system of the second user are retrievable and displayable in the shared panel while each provider system independently maintains separate patient records and without requiring migration of data to a common patient chart or common patient database ([0020]; [0027]; [0041]; [0042]; [0026]).
Ginsburg and Dvorak do not expressly disclose but Cornelius teaches:
--evaluating, via a weighting module of the medical record dashboard system, the plurality of clinical events, wherein the evaluating comprises assigning to each clinical event a base rating value based on an event type and content of the clinical event (claim 9);
--determining, for each clinical event, a correlated event rating value that adjusts the base rating value higher or lower based on at least one other clinical event in the longitudinal record of the same subject patient, including at least one other clinical event received from a provider system different from the provider system that supplied the clinical event being evaluated (claim 6; claim 15);
--determining, for each clinical event, a correlated timeline event rating value that adjusts the correlated event rating value based on a time associated with the clinical event (claim 9; “the system may occasionally adjust the weights automatically as time passes”);
--determining, for each clinical event, a final correlated event rating value from at least the correlated event rating value and the correlated timeline event rating value (claim 1); and
--wherein at least one of an ordering, prominence, grouping, alerting status, or inclusion of a clinical event in the shared panel is a function of the final correlated event rating value for that clinical event (claim 1).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the multi-provider record of Ginsburg and Dvorak to include the relevance weighting of Cornelius because doing so would “present relevant information more prominently in accordance with the information’s relevance to the current condition of the patient” (Cornelius col. 1 lines 31-34), and thus bring the portions of a multi-provider history that bear on the present visit to the reviewing provider’s attention.
Cornelius’s relevance weighting does not affect the normal functioning of Ginsburg and Dvorak’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
The dependent claims of this ground are rejected as set forth below.
Claim
Subject matter
Taught by
159, 163
data received per an interoperability standard including HL7 FHIR; discrete elements assigned base rating values
Ginsburg [0303]; [0178]; Dvorak [0026]; Cornelius claim 9
160, 164
clinical context of the second display (specialty, encounter type, diagnosis) affects what is evaluated and displayed
Ginsburg [0024]; Dvorak [0045]
161
correlated event rating value further accounts for an external context signal: guideline, coverage determination, coverage or claim status
Ginsburg [0025]; [0031]
162, 165
alerting status is a patient-safety alert for a contraindication, interaction, guideline inconsistency, or improper order
Ginsburg [0025]; [0026]
9. Claims 97, 99-103, 105-108, 110, 111, 113-116, 120-122, 124, 126, and 151-157 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), Cornelius (US10431339B1), and Armstrong (US20160283076A1).
The Ginsburg, Dvorak, and Cornelius teachings, and the motivations to combine Dvorak and Cornelius with Ginsburg, are as set forth above. Claims 97, 99-103, 105-108, 110, 111, 113-116, 120-122, 124, 126, and 152-157 depend from claim 151.
Armstrong discloses navigating a chronological record of events at successive levels of detail, in which each event carries a significance determined from importance factors and the significance required for an event to be shown depends on the level being viewed. Armstrong discloses that “[t]he first level event significance may be dynamically determined based on one or more importance factors,” [0004];
--that the factors include “relative importance of the event to other events, social trending of the event, user indication of importance, metadata associated with the event information” [0055];
--that “[i]n some implementations, only events that qualify by having a threshold significance value surface as a card on the search interface 108” [0054];
--that “[f]or example, the threshold of significance may be higher at higher event levels and the lower at decreasing event levels (lower levels). In this manner, events may be considered less significant when viewed in the context of higher levels (e.g., first level) that span longer time periods and more significant when viewed at lower levels (e.g., second level) extending over shorter time periods” [0066];
--that a lower level is requested by “one or more screen taps and/or zoom in touch command (such as a pinching gesture)” [0092];
--that “[f]or example, the threshold value may change to a different value, in which case the significance of the events may be dynamically updated with consideration of the new threshold value” [0065]; and
--that the display is regenerated accordingly, in that “[f]or example, collapsed elements may change to event cards for one or more events with changed significance from less significant to meeting a threshold value of significance” and “[e]vent cards and collapsed elements may be changed to reflect any change in significance of the underlying represented event(s),” [0056].
Regarding claim 151, Ginsburg discloses the receiving, identifying and shared-panel limitations, Dvorak teaches the separate maintenance of the two provider systems and the rendering of both systems’ values into the shared panel without migration, and Cornelius teaches the base rating value, the correlated event rating value, and the correlated timeline event rating value, each as set forth for claim 158 above.
Ginsburg, Dvorak, and Cornelius do not expressly disclose but Armstrong teaches:
--determining, for each clinical event, a final correlated event rating value that adjusts the correlated timeline event rating value based on a zoom level associated with a shared panel of a second display of the second user (“the threshold of significance may be higher at higher event levels and the lower at decreasing event levels (lower levels). In this manner, events may be considered less significant when viewed in the context of higher levels (e.g., first level) that span longer time periods and more significant when viewed at lower levels (e.g., second level) extending over shorter time periods”; “zoom in touch command (such as a pinching gesture)” [0066]);
--generating, from the final correlated event rating values of the plurality of clinical events, a display state comprising one or more of a display order, a visual prominence, an inclusion, a suppression, or an alerting status for each of the plurality of clinical events (“only events that qualify by having a threshold significance value surface as a card on the search interface 108” [0054]; “collapsed elements may change to event cards,” [0056]); and
--updating one or more of the correlated event rating value, the correlated timeline event rating value, or the final correlated event rating value for at least one clinical event, and updating the display state in the shared panel, in response to at least one change in the first data, the second data, the first parameters, or the zoom level (“the threshold value may change to a different value, in which case the significance of the events may be dynamically updated with consideration of the new threshold value, [0065”), the updating being performed via a trigger processing module configured as a rules engine (see Ginsburg [0025]).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the relevance weighting of Ginsburg, Dvorak, and Cornelius to include the level-dependent significance of Armstrong because doing so allows a long chronological record to be reviewed at any span of time without the display becoming cluttered with events that are not significant at that span (Armstrong [0066]and [0054]).
Armstrong’s level-dependent significance does not affect the normal functioning of Ginsburg, Dvorak, and Cornelius’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
The dependent claims of this ground are rejected as set forth below. Claims 97, 99-103, 105-8, 110, 111, 113-116, 120-122, 124, and 126 recite subject matter corresponding to that of claims 166 and 129 and are taught as shown.
Claim
Subject matter
Taught by
97
patient matching by shared identifier, name-and-date-of-birth, or a score over a threshold
Dvorak [0015]; [0021]
99
time parameter and recipient-specialty parameter in the configuration
Ginsburg [0030]; [0024]
100
link to underlying data opened without leaving the panel
Ginsburg [0026]; Dvorak [0046]
101, 116
specialty-specific display configuration
Ginsburg [0024]
102
separately administered instances of the same or different vendor platform
Dvorak [0014]; [0027]
103
encounters from both providers aligned on a unified encounter timeline
Ginsburg [0021]; [0034]; Dvorak [0022]; [0042]
105
panel updated as new data is recorded, without manual re-initiation
Ginsburg [0028]
106
alert or expandable field identifying new information since last rendering
Ginsburg [0026]; [0028]; Dvorak [0034]
107
bidirectional sharing back to the first provider
Ginsburg [0240]-[0241]; Dvorak [0027]
108
web page accessible by link, with input controls for the second user
Ginsburg [0239]; [0290]; Dvorak [0038]
110
standardized exchange interfaces; Data Access Point protocols
Ginsburg [0178]; [0303]; Dvorak [0026]
111
hosted multi-tenant deployment with logically separated data
Ginsburg [0292]; [0058]
113
FHIR application programming interface
Ginsburg [0303]
114
sharing criteria updated as clinical information changes
Ginsburg [0025]; [0028]
115
clinical-relevance score from a machine-learning model
Ginsburg [0031]; Cornelius col. 15 lines 52-55
120
order input, order record, and scheduling-system update
Ginsburg [0022]; [0026]; [0028]
121
notification on an unconfirmed or missed appointment
Ginsburg [0068]; [0031]
122
monitoring for critical clinical events and routing notifications
Ginsburg [0025]; [0026]
124
indexing both providers’ records onto a shared encounter timeline
Ginsburg [0034]; [0021]; Dvorak [0022]
126
automatically determined data presented for review before storage
Ginsburg [0289]
152
data received per HL7 FHIR; discrete elements assigned base rating values
Ginsburg [0303]; [0178]; Cornelius claim 9
153
clinical context of the second display affects which events are evaluated and displayed
Ginsburg [0024]; Dvorak [0045]
154
correlated event rating value further accounts for an external context signal
Ginsburg [0025]; [0031]
155
weighting module stores one or more of the rating values
Cornelius claim 1; Ginsburg [0219]
156
alerting status is a patient-safety alert for a contraindication or improper order
Ginsburg [0025]; [0026]
157
interactions recorded in an audit log accessible through the dashboard
Ginsburg [[0228]; Dvorak [0049]
10. Claims 109, 117-118, 125 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), Cornelius (US10431339B1), Armstrong (US20160283076A1), and Crapo (US20120203571A1).
Claims 109, 117, 118, and 125 depend from claim 151, whose limitations are taught by Ginsburg, Dvorak, Cornelius, and Armstrong as set forth above. The motivation to combine Dvorak with Ginsburg is as set forth above, the motivation to combine Cornelius as set forth above, and the motivation to combine Armstrong as set forth above.
Crapo discloses managing patient consent to the exchange of a patient’s records among health care entities that each keep their own records, by recording the patient’s authorization and the restrictions on it and enforcing them when access is requested. Crapo discloses that “[t]he health care entities 125 maintain separate systems with their own information and access patient information stored by other entities via the network 105,” [0036];
--that the patient authorizes the exchange and may withdraw that authorization (“the patient can opt-in to having the patient’s information exchanged over the network 105 by providing an affirmative authorization by signing a consent form. The patient can also opt-in with restrictions, such as identifying types of information that the patient wants kept confidential. The patient can also opt-out of having the patient’s information exchanged over the network 105 by formally requesting that the data not be exchanged,” [0072]; “Options 313 determine whether a user is allowed to access various types of clinical data. For example, a user may be allowed to access lab work, medication history, pathology reports, etc,” [0082]; “the lookup module 202 hides the confidential data from the user,” [0090]);
--that the restrictions on the authorization include a duration (“The user opts-in with restrictions and opts-out with exceptions. The restrictions include a time limit, a provider and a data type,” [0079]);
--that the requesting user selects the term of access and a bounded term carries an expiry (“The user selects at least one of a one-time access option 333 and a long-term option 334. The long term option 334 requires a date/time when the access expires,” [0087]); and
--that the expiry is enforced (“the clinical authorization engine 203 prevents the user from accessing patient information because the time limit for providing access to the patient data has expired,” [0058]).
Regarding claim 117, Ginsburg discloses the grant of access to a second user and its restriction in what it reaches ([0223]). Ginsburg, Dvorak, Cornelius, and Armstrong do not expressly disclose but Crapo teaches: wherein the second user is provided access to the selected first data upon a patient authorization, and wherein the patient authorization is limited in duration ([0072]; [0079]; [0087]; [0058]).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the shared access of Ginsburg, Dvorak, Cornelius, and Armstrong to include the consent management of Crapo because recording the patient’s authorization and its restrictions, and enforcing them when access is requested, is what permits records to be exchanged among entities that “maintain separate systems with their own information” (Crapo [0036]) without exposing the patient’s data beyond what the patient allowed.
Crapo’s consent management does not affect the normal functioning of Ginsburg, Dvorak, Cornelius, and Armstrong’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
Regarding claim 118, Ginsburg, Dvorak, Cornelius, and Armstrong do not expressly disclose but Crapo teaches: wherein the patient authorization is revocable and access is discontinued upon its revocation or expiry ([0072]; [0058]).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the shared access of Ginsburg and Dvorak to include the consent management of Crapo because recording the patient’s authorization and its restrictions, and enforcing them when access is requested, is what permits records to be exchanged among entities that “maintain separate systems with their own information” (Crapo [0036]) without exposing the patient’s data beyond what the patient allowed.
Crapo’s consent management does not affect the normal functioning of Ginsburg, Dvorak, Cornelius, and Armstrong’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
The remaining claims of this ground are rejected as shown below.
Claim
Subject matter
Taught by
109, 125
per-recipient access parameters; suppression of restricted categories
Crapo [0082]; [0079]; [0058]; [0090]; [0060]
11. Claims 98, 112, and 128 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), Cornelius (US10431339B1), Armstrong (US20160283076A1), and Bucur (US20130080192A1).
Claims 98, 112, and 128 depend from claim 151, whose limitations are taught by Ginsburg, Dvorak, Cornelius, and Armstrong as set forth above. The motivation to combine Dvorak with Ginsburg is as set forth above, the motivation to combine Cornelius as set forth above, and the motivation to combine Armstrong as set forth above.
Bucur discloses matching a pair of patient records held by different institutions as belonging to the same patient by scoring the agreement of their clinical properties against a set of matching rules. Bucur discloses extracting clinical properties from each of the two records and detecting whether they relate to the same patient on the basis of those properties and the matching rules (claim 1);
--that the clinical properties used include “known allergies, image data and other measurements,” and “various lab data such as blood group, detected antibodies and persistent viral infections,” [0050];
--that “[w]eights may be assigned to each of the clinical data items and/or rules to be used in the matching algorithm,” [0055];
--that the match detector performs “determining a matching score for the pair of patient records, based on the set of matching rules and the set of corresponding weights” (claim 3);
--that in matching a record held by one hospital against records held by another, “[t]he clinical data may be matched according to the rules set in the defined profile. A total score may be computed and a decision taken to match the two records or reject the match,” [0056]; and
--that the decision is taken by comparison against a threshold, the records being linked automatically unless “the computed likelihood falls between the accept and reject thresholds,” in which case the pair is submitted for “manual review”, [0004].
Regarding claim 98, Ginsburg and Dvorak do not expressly disclose but Bucur teaches: wherein resolving an identity of the same subject patient across the provider systems comprises collecting different classifications of patient-related data for the same subject patient, the different classifications comprising at least one of active problems or diagnoses, allergies, medications, procedures, diagnostic test results, or clinical findings from each of the respective provider systems ([0050]); determining level-of-accuracy scores for each of the patient-related data of the different classifications collected ([0055]; claim 3); adding the level-of-accuracy scores to obtain a total of the added level-of-accuracy scores ([0056]); and comparing that total to a previously determined matching threshold and establishing that the records correspond to the same subject patient when the total exceeds the matching threshold ([0004]).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the patient identification of Ginsburg, Dvorak, Cornelius, and Armstrong to include the clinical-property scoring of Bucur because using clinical information in addition to demographic information “may improve the record matching and/or reduce the number of records submitted” for manual review (Bucur [0011]).
Bucur’s scored matching does not affect the normal functioning of Ginsburg, Dvorak, Cornelius, Armstrong’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
Claim 112 is substantially similar to claim 98 and is rejected with the same reasoning.
Regarding claim 128, Ginsburg and Dvorak further disclose the shared display configuration stored at a network-accessible configuration store used by a health information exchange network, and communication with the record systems of a plurality of participating providers (Ginsburg [0298]; Dvorak [0017]; [0027]), and Bucur teaches the scored patient-matching process as set forth for claim 98.
12. Claims 141 and 145 are rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), McNair (US20150193583A1), and Bucur (US20130080192A1).
Claims 141 and 145 depend from claim 129, whose limitations are taught by Ginsburg, Dvorak, and McNair as set forth above. The motivation to combine Dvorak with Ginsburg is as set forth above and the motivation to combine McNair as set forth above. The Bucur teachings, and the motivation to combine Bucur, are as set forth above.
Claim 141 is substantially similar to claim 98 and is rejected with the same reasoning. Claim 145 is substantially similar to claim 128 and is rejected with the same reasoning.
13. Claim 104 is rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), Cornelius (US10431339B1), Armstrong (US20160283076A1), and Faulkner (US20090216562A1).
Claim 104 depends from claim 151, whose limitations are taught by Ginsburg, Dvorak, Cornelius, and Armstrong as set forth above. The motivation to combine Dvorak with Ginsburg is as set forth above, the motivation to combine Cornelius as set forth above, and the motivation to combine Armstrong as set forth above.
Faulkner discloses aggregating a patient’s clinical records collected from the electronic medical record systems of two or more separate healthcare institutions into a single display, and marking the displayed data with an identification of the institution it came from. Faulkner discloses that “[e]ach category 52, is identified as to the healthcare provider 12 to which it is related by an icon block 54 depicting a trademark, logo or other symbol or text element identifying the healthcare provider 12, and visually linked thereto, for example, by proximity or a common frame or other visual device, [0045]”;
--that “[t]he icon blocks 54 may provide hyperlinks to the health data portals of the institutions 12 and 14” [0046]; and
--collecting clinical records “from the electronic medical record systems of the healthcare institutions over the computer network,” (claim 1)
--displaying “the clinical medical data visually aggregated by datatypes,” [0008] and
--“visually associat[ing] the visually aggregated clinical medical data with information identifying the healthcare institutions sourcing the clinical medical data,” the identifying information being “a logo for the healthcare institution” (claim 2).
Regarding claim 104, Ginsburg, Dvorak, Cornelius, and Armstrong do not expressly disclose but Faulkner teaches: wherein each value in the shared panel has a first visual indicator that identifies an originating medical practice or originating provider associated with that value (claim 1; claim 2). Ginsburg further discloses the additional visual indicator and its automatic update to represent clinical status ([0029]; [0172]).
One of ordinary skill in the art before the effective filing date would have been motivated to expand the shared panel of Ginsburg, Dvorak, Cornelius, and Armstrong to include the institution identification of Faulkner because marking each item with the institution it came from “eliminates confusion as to the source of the healthcare information that would normally be available from context from the individual websites but where the context is lost by the aggregation” [0045] (Faulkner).
Faulkner’s institution identification does not affect the normal functioning of Ginsburg, Dvorak, Cornelius, and Armstrong’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
14. Claim 170 is rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1), McNair (US20150193583A1), and Faulkner (US20090216562A1).
Claim 170 depends from claim 166, whose limitations are taught by Ginsburg and Dvorak as set forth above, and the motivation to combine Dvorak with Ginsburg is as set forth above. The McNair teachings, and the motivation to combine McNair, are as set forth above; the Faulkner teachings, and the motivation to combine Faulkner, are as set forth above.
Regarding claim 170, Ginsburg discloses the trigger processing module configured as a rules engine ([0025]) and the representations applied to a rendered data element, namely an Alerted Data Representation ([0026]), an Informational Data Representation ([0021]; [0029]), and a Linked Image Data Representation ([0026]), together with update of the panel in response to new encounter data ([0028]). Dvorak teaches a Linked Data Representation carried by the rendered element itself, each row of the returned event table carrying a code by which the underlying report is retrieved ([0046]; [0026]).
Ginsburg and Dvorak do not expressly disclose but McNair teaches: wherein the rules engine applies the shared display configuration at rendering time, each data element rendered at the shared panel being subjected to the trigger processing module to determine the representation to be applied to that data element ([0028]; [0029]).
Ginsburg, Dvorak, and McNair do not expressly disclose but Faulkner teaches: such that values originating from the first medical care provider and values originating from the second medical care provider are visually distinguished at the shared panel (claim 1; claim 2).
Each element is taught by Ginsburg, Dvorak, McNair, or Faulkner, and neither McNair’s chart-opening evaluation nor Faulkner’s institution identification affects the normal functioning of Ginsburg’s display panels and patient flowsheet, so the combination is no more than an assembly of old elements, each performing as it did separately, with predictable results, and it would therefore have been obvious to one of ordinary skill in the art before the effective filing date to combine them.
15. Claim 172 is rejected under 35 U.S.C. 103 as being unpatentable over Ginsburg (US20170116373A1) in view of Dvorak (US20030139943A1) and Faulkner (US20090216562A1).
Claim 172 depends from claim 166, whose limitations are taught by Ginsburg and Dvorak as set forth above, and the motivation to combine Dvorak with Ginsburg is as set forth in that paragraph. The Faulkner teachings, and the motivation to combine Faulkner, are as set forth above.
Regarding claim 172, Ginsburg discloses that the underlying information is viewable without the user leaving the display in which the panel is presented ([0026]), and Dvorak teaches that the assembled result is presented to the user as a single record ([0026]; [0017]). Ginsburg and Dvorak do not expressly disclose but Faulkner teaches: wherein visual indicators distinguish the displayed values according to the database from which each originated (claim 1; claim 2).
Response to arguments
Applicant's arguments filed 08/26/2026 have been fully considered and are discussed below.
(Step 2A Prong One) Applicant argues that claim 151 recites neither identified exception because it recites “no sharing step, no referral, no consultation, no co-management workflow, no selection interface by which one provider designates information for another, no patient authorization or consent, and no access-control determination”; that limitation (d) cannot practically be performed in the mind because a zoom level is a state parameter of a rendered machine display and there is no mental or pen-and-paper analogue to recomputing the weight of every clinical event as a function of that state, MPEP 2106.04(a)(2)(III)(C); and that the same arguments reach claims 158 and 166, which are said to mirror claim 151. Remarks pages 35-36, 43. Applicant is correct that claim 151 recites none of the steps identified in the prior Office action, and the Prong One analysis has been restated above to identify the mental process claim 151 does recite. Applicant confuses “zoom level” as used in the specification (e.g., [0351]-[0358] as published) referring to the time span of data being displayed with the plain meaning of zoom level in a GUI sense where it refers to an amount of magnification with which a graphic is viewed. Weighing which events matter at a one-year view of a history and which matter at a ten-year view is the act of summarizing that history at a chosen scope, and reciting a display parameter as an input to an evaluation does not remove the evaluation from the mental processes grouping. The arguments do not reach claims 158-165 or 166-172 because claim 158 recites no zoom-level stage, no display state and no updating step, and claim 166 recites none of the four rating values, no weighting module and no display state.
(Step 2A Prong Two) Applicant argues that claim 151 produces the display state itself rather than reporting the result of an analysis and is therefore an improvement under MPEP 2106.05(a); that claim 166's recitation of display without migration of patient-related data to a common patient chart or a common patient database is an architecture rather than a field-of-use constraint; and that the prior Office action was internally inconsistent in finding no improvement to computer functioning at Prong Two while stating in the § 103 rejection that the combination would improve the ability of electronic medical record systems to communicate. Remarks pages 37, 41-42. The Prong Two analysis has been restated above and the statement Applicant identifies is not carried forward. The remaining arguments are not persuasive because a display order, a visual prominence, an inclusion, a suppression or an alerting status is the form in which the result of the recited evaluation is presented, and producing that result is not a change in the manner in which the display system, the medical record databases or the rules engine operates. Applicant's specification frames the technical problem as presenting multi-source data in a single interface without unacceptable delay (i.e., [0009] as published). The recited ratings are a ranking of clinical events and no mechanism addressing that problem is claimed. An improvement described in the specification but not reflected in the claims does not integrate the exception into a practical application. MPEP 2106.05(a). The recitation that values are displayed without requiring migration to a common patient chart or a common patient database is functional result of a storage system that uses rules to constrain generic data access. MPEP 2106.05(f) and (h).
(Step 2B) Applicant argues that the findings of well-understood, routine and conventional activity in the prior Office action address elements claim 151 does not recite, and that no factual finding has been made that the four-stage ordered combination of rating values is well-understood, routine or conventional. Remarks page 39. This is not persuasive because the elements evaluated at Step 2B are the elements recited beyond the judicial exception, which in claim 151 are the one or more processors, the memory storing instructions, the weighting module, the trigger processing module configured as a rules engine, the receiving of the first data and the second data, and the generating of the display state; the four-stage evaluation is the judicial exception itself and is not an additional element to be evaluated at Step 2B. MPEP 2106.05. To the extent Applicant contends that the evaluation as an ordered combination supplies an inventive concept, the sequence of scoring a clinical event, adjusting that score for related events in the record, discounting it for the age of the event, scaling it to the span at which the record is viewed, and redrawing the display accordingly was well-understood, routine and conventional before the effective filing date, as shown by Cornelius, Armstrong and McNair applied above. MPEP 2106.05(d)(I).
Applicant states that new claim 166 mirrors the elements of new claim 151, Remarks page 35, and that new claim 158 mirrors the elements of new claim 151, Remarks page 43. Neither claim does. Claim 158 recites no zoom-level stage, no display state and no updating step. Claim 166 recites none of the four rating values, no weighting module and no display state; it recites the shared display configuration architecture instead. The arguments Applicant directs to the limitations of claim 151 therefore do not reach claims 158-165 or claims 166-172.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office Action (See MPEP 706.07(a)). Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA BLANCHETTE whose telephone number is (571)272-2299. The examiner can normally be reached on Monday - Thursday 7:30AM - 6: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, Shahid Merchant, can be reached on (571) 270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOSHUA B BLANCHETTE/ Primary Examiner, Art Unit 3624
Prosecution Insights