SYSTEMS AND METHODS FOR MANAGING ELECTRONIC HEALTHCARE INFORMATION

Abstract

This invention relates to systems and methods for managing electronic healthcare information on a highly scalable and customizable software and hardware architecture which emphasizes portable devices and minimal downtime during upgrades and scaling. This invention further relates to systems and methods for efficient access and customization of forms for electronically generating and managing patient information. In one aspect of the invention, an electronic health record system (EHR) of the present invention, which may also be referred to as an electronic medical record system (EMR), may be deployed and run on a plurality of servers over which the computing and/or storage load may be distributed in a non-centralized manner such that the overall system may remain up and operating even while being scaled, upgraded and/or otherwise modified.

Claims

1. A method for implementing and customizing an electronic health record (EHR) system at a healthcare institution comprising: providing a server component of an EHR system to an institution on at least one server, said EHR system including software for configuring said at least one server to interface with a plurality of user access devices hosting a client component of said EHR system and including underlying data handling features for handling of information being capable of creating, adding information to and retrieving information from hierarchically-structured data (HSD) documents stored on a storage device in a set of separate of files from said software; creating a series of system object HSD documents which define a plurality of system objects, said system objects defining the manner that information is displayed to and gathered from users on said client component of said EHR system and further defining the data structure of said information to be inserted into HSD documents for saving and storage; and customizing said EHR system on said at least one server by customizing the input and output configuration of said system objects by modifying at least one of said system object HSD documents to create customized system objects which conform with the institutional practices of said institution, wherein said customizing does not alter said software or other HSD documents; wherein said customizing creates a production version of said EHR system for active use.

2. The method of claim 1, wherein said at least one server comprises a testing server and a production server, said testing server storing and running said EHR system during said customizing and being adapted to push said production version of said EHR system to said production server for active use.

3. The method of claim 1, further comprising training said users on operating said system objects after said customizing of said EHR system by utilizing said client component of said EHR system interfaced with said at least one server.

4. The method of claim 1, wherein said EHR system stores and retrieves healthcare information by creating, accessing or modifying said HSD documents and does not modify said system object HSD documents or said software.

5. The method of claim 1, further comprising creating a customized user interface by defining a set of said system object HSD documents, said system object HSD documents being utilized by said plurality of user access devices to generate a graphical user interface for displaying and gathering healthcare information.

6-41. (canceled)

42. A method for implementing and customizing an electronic record management (ERM) system at an institution comprising: providing a server version of an ERM system to an institution on at least one server, said ERM system including software for configuring said at least one server to interface with a plurality of user access devices hosting a client version of said ERM system and including underlying data handling features for handling of information being capable of creating, adding information to and retrieving information from hierarchically-structured data (HSD) documents stored on a storage device as separate files from said software; creating a series of system object HSD documents which define a plurality of system objects, said system objects defining the manner that institutional information is displayed to and gathered from users on said client version of said ERM system and further defining the data structure of said institutional information to be inserted into HSD documents for saving and storage; and customizing said ERM system on said at least one server by customizing the input and output configuration of said system objects by modifying at least one of said system object HSD documents to create customized system objects which conform with the institutional practices of said institution, wherein said customizing does not alter said software or other HSD documents; wherein said customizing creates a production version of said ERM system for active use.

43. (canceled)

44. The method of claim 42, wherein said institutional information is selected from the group consisting of electronic healthcare information, human resource management information, accounting information, project management information, customer relationship information and campaign management information.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0090] FIGS. 1 and 1a illustrate dashboard views of the user interface of an EHR system of the present invention;

[0091] FIG. 2 illustrates a work queue view of the user interface of an EHR system of the present invention;

[0092] FIG. 3 illustrates a set of appointment and scheduling widgets in a view of the user interface of an EHR system of the present invention;

[0093] FIGS. 4 and 4a illustrate sets of patient information widgets and a TOC in a view of the user interface of an EHR system of the present invention;

[0094] FIGS. 5 and 5a illustrate auto-filling behavior in certain input fields of widgets in a form;

[0095] FIGS. 6 and 6a illustrate TOC sub-level behaviors in the user interface of an EHR system of the present invention;

[0096] FIGS. 7 and 7a illustrate a system object editor accessible from the user interface of an EHR system of the present invention;

[0097] FIG. 8 illustrates an example of a form with a variety of widgets in a view of an EHR system of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0098] The detailed description set forth below is intended as a description of the presently exemplified systems, devices, methods and materials provided in accordance with aspects of the present invention, and it is not intended to represent the only forms in which the present invention may be practiced or utilized. It is to be understood, however, that the same or equivalent functions and components may be accomplished by different embodiments that are also intended to be encompassed within the spirit and scope of the invention.

[0099] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which this invention belongs. Although any systems, methods, devices and materials similar or equivalent to those described herein can be used in the practice or testing of the invention, the exemplified systems, methods, devices and materials are now described.

[0100] The names of persons appearing herein, either in the written specification or in the drawings, are intended to be completely fictitious and do not represent any real persons, living or dead. Any similarity to the name or characteristics of a real person is completely unintentional, coincidental, meant to be obviously fictitious and/or for illustrative purposes only. Nothing herein should constitute or construed to be professional advice or treatment.

[0101] As mentioned above, one of the biggest expenses in bringing any EHR online for a group of medical professionals is the time spent implementing an institution's existing workflows and processes within the system. Although most institutions share the same basic concepts of encounter, patient account, order, laboratory result, and protocol, the exact way these concepts are stitched together to drive patient care from admission to discharge can differ significantly even from hospital to hospital. Often it takes a gradual process to identify and discern the interconnections amongst the different pieces of an institution's workflows and processes. To sustain this journey, EHR systems need to accommodate small, incremental, potentially frequent changes to the system configuration in order to “get it right”. At odds with this requirement is the fact that the definitions of forms, workflows, and other aspects of the system are sometimes hard-coded into the EHR itself, requiring the allocation of highly-skilled developers' time to implement. Once institutional customizations start to entail changes in the underlying EHR product, the notion of frequent incremental changes can turn out to be impractical. This is especially so for EHRs that requires downtime to accomplish any changes or upgrades.

[0102] Previous generation systems were also often designed to run on a single server. When the single server became overloaded, the solution was often to replace the server with a larger, more powerful server. High availability was achieved by doing everything possible to keep that single server from failing and having an identical backup server on standby. Finally, upgrades were performed by scheduling an outage for the server and updating the software and doing a smoke test as quickly as possible to minimize downtime.

[0103] The present invention relates to systems and methods for inputting information electronically and for storing such information on multiple servers, which may include cloud servers, for easy accessing, managing, sharing, and organizing such information with minimal down time during scaling and upgrading. Unlike exiting systems, the present invention is designed to run across multiple servers and to distribute the workload evenly across these servers. Because every tier of the application includes essentially identically-configured worker nodes, individual nodes can fail and/or be taken down for maintenance or upgrades while minimally impacting the availability of the overall system. To support a larger number of users or records, one simply adds more servers to these pools.

[0104] In addition to highly scalable and customizable software and hardware architecture to minimize downtime during upgrades and scaling, the present invention also emphasizes portable devices.

[0105] In one aspect of the invention, an electronic health record system (EHR) of the present invention, which may also be referred to as an electronic medical record system (EMIR), may be deployed and run on a plurality of servers over which the computing and/or storage load may be distributed in a non-centralized manner such that the overall system may remain up and operating even while being scaled, upgraded and/or otherwise modified. In some exemplary embodiments, an EHR system of the present invention may be a software application that may generally include a plurality of essentially identically configured worker nodes that are deployed and run on a plurality of servers in a server pool. In the present invention, the EHR system may distribute its workload and/or storage load across the servers in the server pool, such as, for example, substantially evenly across the available servers in the server pool. Since the EHR system may include a plurality of essentially identically configured worker nodes, individual worker nodes may be taken down, fail, and/or be modified without affecting the other worker nodes and/or significantly impacting the overall operability of the EHR system. This may be desirable as the EHR system runs the operations of any healthcare facility and in such medical settings where the need to access patient information is, for example, often time-sensitive and essential for proper patient treatment, experiencing minimal or no downtime once deployed may insure smooth operations without unnecessary interruptions. In this manner, for example, the server pool may have additional servers added in and/or servers taken down, whether for replacement, upgrade, repair or otherwise, at almost any given time to modify the system experiencing downtime due to server modifications, thus minimally impacting the availability of the overall system.

[0106] In some embodiments, the EHR system of the present invention may be built on a highly-automated installation platform where individual components of the system may be packaged into separate images, which may include the configurations of the specific components. The system may create and run instances of the components from the images while keeping any data generated meant to be persistent stored separately from the image in persistent storage. Thus, the system may create and dispose of instances of the components at will without loss of either configuration information, which is stored in the image, or persistent data, which is stored in persistent storage. The separate EHR system components may then be taken down for upgrades, repairs and/or other modifications without affecting other components.

[0107] In one embodiment, the EHR system of the present invention may be built on an automated installation platform, for example, “Docker”. “Docker” may generally leverage Linux Containers, a technology built into Linux that is lighter weight than traditional virtualization methods. The components of the EHR system of the present invention may then be packaged into “Docker” images. Images may then be started within “Docker” to produce running instances of the components. In a traditional environment, for example, these instances may be akin to an installed piece of software running on a stack of middleware and other components for which significant time and energy are invested in configuration. In contrast, instances of the EHR components in this embodiment may generally be easy to create and may be disposable when, for example, repairs, upgrades and/or modifications to the EHR system are desired or necessary. “Docker” may also generally allow for separation of configuration data for each component, which may be stored in the “Docker” image, and persistent data, which may be stored in persistent storage. The instances of each component may thus be disposed of at any time because the configuration of the instance may be recreated at any time by, for example, launching a new instance based on the same original image, while the persistent data managed by the instance is not stored in the instance itself but in a persistent storage, such as a backend, for example, a network attached storage (NAS).

[0108] In some embodiments, persistent data may be stored using a scalable backend database system which may generally utilize non-relational database structures, but may rather utilize a discrete document-centric structure which may further leverage scalability, document replication and/or load distribution on a server or storage pool. The database system may also, for further example, utilize a document checkout system where documents remain viewable to all allowed users, but only one user may modify the document at a time by checking it out of the database. This may be desirable to prevent, for example, concurrent modification of documents which may introduce conflicting information. This is especially desirable in the healthcare area, where conflicting information may have life and death consequences.

[0109] In one exemplary embodiment, the scalable backend database system may employ a NoSQL database such as, for example, “MongoDB”. Some databases, such as “MongoDB”, may be specifically designed to manage and store extremely large numbers of HSD documents such as JSON documents in a scalable fashion.

[0110] In another aspect of the invention, the EHR system may be designed to be primarily accessed, maintained and utilized almost entirely from portable or mobile devices with only certain functions requiring direct access to a server and/or a stationary computer. This is unlike most EHR systems in general, which are designed for use with stationary computers with any mobile access or functionality being an afterthought. This in general reflects a more traditional or dated approach to maintaining health records which are more akin to paper and file room systems that do not significantly leverage any technological advances that allow for a different approach to managing information. In this aspect, the EHR system of the present invention may generally be utilized immediately and at the point of contact with patients and/or during actual occurrences requiring entry and/or retrieval of information, rather than after the fact. This may, for example, aid in increasing efficiency and/or fidelity of information as after-the-fact recordkeeping may inherently introduce error and/or incompleteness due to later inaccessibility to the source of information.

[0111] In general, accountability and auditability are important concepts in the medical field. As accurate patient records are relied heavily upon to make informed clinical decisions, the EHR system of the present invention may be designed to track all changes that occur to patient records by, for example, date, time, user and/or any other appropriate manner. The EHR system may also generally store all and/or a desired selection of past versions of documents in the database to facilitate audits. Users of the EHR system may also facilitate auditability through the use of the check-in and check-out actions available in the EHR system, as these actions may generally, for example, also prevent multiple users from making potentially conflicting modifications to any given document.

[0112] In some embodiments, all primary users of the EHR system of the present invention may utilize a portable or mobile device for their access and utilization of the EHR system. In one embodiment, iPad®, Android®, Windows® tablets and/or other similar tablet computing devices may generally be utilized. In general, it may be desirable for the EHR system of the present invention to be utilized from a popular, widespread and/or familiar computing platform, as this may allow, for example, users to concentrate on their actual tasks rather than trying to figure out an unfamiliar and/or overly complex software interface. In addition, popular and/or widespread computing platforms may generally benefit from diligent technical support, issue familiarity, updates and/or availability of replacements. The EHR system of the present invention may generally be utilized on any appropriate device, which may include, but is not limited to, a smartphone, a tablet computer, a personal computer, and/or any other appropriate computing device. In general, the EHR system of the present invention may employ a graphical user interface (GUI) and depending on the device, it may be accessible with a touchscreen interface and/or a keyboard/mouse interface, whichever may be appropriate. The EHR system of the present invention may also employ other forms of interface, such as those designed for use with visually and/or hearing impaired users, and/or alternative interfaces, which may include, for example, voice recognition and/or playback, Braille computer interfaces, haptic interfaces, and/or any other appropriate interface.

[0113] In a further aspect of the invention, the EHR system of the present invention may utilize a highly customizable architecture that may generally enable the EHR system to be customized to fit any particular needs of the user(s) without any drastic changes to the underlying functionality and/or design of the EHR system. In some exemplary embodiments, the EHR system architecture of the present invention may be based on having the configuration of most aspects of the system exposed to administrators in the form of system objects, where, for example, changes including, but no limited to, adding a field to a form to creating a new workflow for handling lab orders are all achievable without changes to the underlying EHR system of the present invention. System objects may generally be defined using the YAML syntax and may exist as HSD documents such as JavaScript Object Notation (JSON) documents in a similar fashion to all other documents (such as patient records) managed by the EHR system.

[0114] With most existing EHRs, there is a common problem: forms and processes need customization to meet the needs of individual institutions, for example, hospitals. To solve this problem, most of these EHRs employ hard-coding form and process definitions in code, which requires additional time and higher-skilled developers to create multiple custom versions of the product. That means either multiple versions of the electronic health record system software need to be created and stored on at least one server; or a higher-skilled developer may take time to create a custom version ad hoc, hampering the operation of the institution. Also, when multiple institutions want to have different customizations to their electronic health record system and if multiple versions of the device and/or server software are not created beforehand, these requirements for higher skilled developers and time can multiply.

[0115] The present invention solves the above mentioned defects and eliminates the need for higher skilled developers when custom forms are needed ad hoc without creating multiple versions of the electronic health record system software by leveraging the flexibility of documents storing data with a standardized syntax or format, such as for example, HSD documents such as JSON documents and a unique manner in which HSD documents such as JSON documents are dynamically processed on any appropriate device mentioned above. For example, health records may be stored as a series of HSD documents such as JSON documents on at least one computer server.

[0116] The present invention may utilize a form engine, for example, that may work off of form definitions that are provided as configuration files to the product. In this way, a lower skill level only is needed to customize the EHR for a specific hospital, and custom forms and processes may be defined in configuration files that may be updated without the need for custom versions of the base product.

[0117] For example, the form engine may work as follows: when a document is to be shown in the EHR to a user, the form engine retrieves the document from the database. Documents may be encoded as a series of key-value pairs in HSD such as JSON format. One of the key-value pairs may indicate the form template the document is based on. The EHR may then retrieve the form template from the database, which may itself also be specified as a series of key-value pairs in HSD such as JSON format. Form templates specify what fields may be shown on the screen (e.g., a field for gender or age), what kind of “widget” is to be used to capture the input from the user (e.g., a choice widget or a search widget for looking up a code), and how to store the value inputted by the user in the document (usually giving the “key” name for the key-value pair in the HSD document such as JSON document). In the final step, the EHR's form engine may create the actual form presentation on the screen of a user device, such as an iPad, one widget at a time, in sequence, reflecting the latest customizations at the time, and then populates the widgets with data from the document.

[0118] The present invention is also different from normal paper forms or forms in other applications, in addition to being more efficient and time saving. First, the forms are not hard coded, so only a configuration change may be needed to update/customize forms. Development skills are not needed for the personnel implementing the change, and a new version of the product does not need to be produced and/or a master form be printed and/or filed. Also, as the forms are not hard coded, the exact presentation shown to the user on the iPad may be optimized by the form engine at runtime. For example, with hard-coded forms, layout characteristics such as fonts and positioning on the screen are set explicitly. With the present invention, using the form engine, one abstract form layout specification may be used to produce a form user interface for a user device, such as an iPad, in landscape mode, portrait mode, and even for use in a web browser, depending on the space available on the screen. Further, the form input screens always reflect the very latest version prepared by the system administrators. There is no upgrade to be done to the iPads, the servers, or even to the data already filled in using old versions of the forms (in many cases). This is clearly in contrast with paper forms, where updates to the form template itself will not propagate back to copies of the forms that were already filled in. Furthermore, it is easier to control versioning on a per-form basis. For example, it is possible for multiple institutions to share form templates and be aware of the dates individual form templates were updated on. A given hospital may choose to roll out a new demographics form while delaying the roll out of a form used to capture vitals. This may not be possible in and is clearly in contrast to a system with hard-coded forms, where every permutation of different form template versions would require a different version of the product itself, a combinatoric explosion which may result in an unmanageable number of versions for an EHR vendor to track and keep up to date. Thus, in addition to not requiring higher-skilled developers, the present invention further simplifies not only the process, but minimizes the number of versions to track, thus minimizing the chances for confusion, and save time and effort.

[0119] In yet another aspect of the present invention, the EHR system of the present invention may be efficiently and easily customized for installation at a working site, such as, for example, a hospital, doctor's office, and/or other healthcare institution, without a great deal of “back end” customization of the EHR system in order to achieve a working implementation. In general, one of the biggest expenses in bringing an EHR online for a group of medical professionals is the time spent implementing an institution's existing workflows and processes within the system. Although most institutions share the same basic concepts of encounter, patient account, order, laboratory result, protocol, and/or others, the exact way these concepts are stitched together to drive patient care from admission to discharge can differ significantly from one institution to another. In many situations, a gradual process is used during a typical EHR implementation to identify and discern the interconnections amongst the different pieces of an institution's workflows and processes. Effective EHR systems are generally designed to accommodate small, incremental, potentially frequent changes to the system configuration in order to properly implement the EHR system so that it will work with the institution. Often, the definitions of forms, workflows, and other aspects of the system are sometimes hard-coded into the EHR itself, which often requires the allocation of highly-skilled developers' time to implement due to the required changes being done on the “back end”. Further in general, once institutional customizations start to entail changes in the underlying EHR product, the notion of frequent incremental changes can become impractical.

[0120] In some exemplary embodiments, the EHR system of the present invention may be based on having the configuration of most aspects of the system exposed to administrators in the form of system objects, which may, for example, be defined using YAML syntax and exist as HSD documents such as JSON documents in the system, as discussed above. In this fashion, various changes and/or modifications to the exposed “front end” of the EHR system may be achieved without altering the underlying EHR system “back end”. Changes and/or modifications may include, but are not limited to, modifying forms, creating new workflows, customizing reports, creating and/or modifying information input and/or display features, and/or any other appropriate changes or modifications.

[0121] In some embodiments, the EHR system of the present invention may employ a basic system object, such as, for example, a template, which may define how information and/or collections of information are presented to a user, such as in a visual representation, for example, a form, and/or how inputted information is structured and/or recorded in the EHR system.

[0122] In some embodiments, a template may be used to display and/or organize a series of individual information presenting and/or gathering components to a user as a form, which may be visually similar to electronic and/or paper forms commonly employed in a healthcare setting. For example, the individual information presenting and/or gathering components may be form widgets, such as, for example, HTML widgets, which may then be utilized by a user as the interface on a device for entering and/or retrieving information. The form widgets themselves may be embedded into the forms and/or reports being displayed on the user interface of the EHR system of the present invention. The information and structure of the information may then be stored within a HSD document, for example, JSON document in the persistent storage of the EHR system of the present invention.

[0123] FIGS. 1 and 1a illustrate examples of a dashboard view 100 of the EHR system for a user in some embodiments of the invention. The EHR system user interface may generally indicate which user is logged in, if any, such as with the user logged in indicator 102, and may also generally provide a logout button 103. Information displayed in the EHR system user interface may generally be arranged in columns which may be customized to a user's preferences and/or to particular needs for tasks and/or situations, such as illustrated with columns A, B and C in FIG. 1.

[0124] A variety of widgets may be utilized, such as to simplify gathering different kinds of information, and may include, but are not limited to, text inputs, dates and times, blood pressure readings, codes based on a standard vocabulary, pictures and/or photos taken from the device, and/or any other appropriate widget. Widgets may also be divided into sections and tables in order to facilitate navigation. As data is collected from the user, values for the information may be recorded via the widget, which may further be recorded under keys that are defined by the template, and placed into a HSD document, for example, a JSON document. In this manner, the user interface of the form may be utilized to present the underlying HSD document, for example JSON document for inspection and modification by the user in a user-friendly, administrator-defined fashion, as per the template utilized.

[0125] In some embodiments, as illustrated in FIG. 1, the dashboard view 100 may, for example, contain a variety of widgets which may be defined by the template governing the dashboard view 100. Widgets may include, for further example, a navigation bar 110 for showing different views of the EHR system, such as, for example, the overview as shown in the dashboard view 100, the work queue view via button 112 of the user, reports via button 114, checked out documents via button 116 and via button appointments 118, a listing of patients 121 accessible and/or assigned to the user, such as in patient list 120, a schedule of appointments 130, and/or other appropriate widgets, such as, for further example, barcode scanner 140 and admin controls 150, as illustrated. FIG. 1a illustrates a dashboard view 100 with an example of an alternative arrangement and differing widgets and controls, as shown with navigation bar 110, for example, with buttons 111, 113, 116 for a particular professional (e.g. physician), overview and checked out documents, an upcoming procedures listing 130′, active patient list 120′ with patients 121′ and an approval queue 160, as illustrated.

[0126] FIG. 3 illustrates a view in the EHR system of a schedule of appointments 300 which may be accessible from the schedule of appointments button 118. The schedule of appointments 300 may include widgets for displaying existing appointments and/or enable entry/modification of appointments into a calendar of a user.

[0127] In some embodiments, macro sets may be utilized to specify a set of macros to appear in the EHR system of the present invention when information is being manipulated in the user interface. For example, when a macro button is pressed, the text corresponding to that macro button may be inserted into an active text field. The text may be dynamically generated by a script defined in the macro set that, when run by the mobile device, obtains potentially context-relevant data from at least one computer server such as a patient's allergies or demographic information to include in the inserted text. Macro sets may be targeted at specific fields on forms, specific users, and/or specific groups. In this way, users who have a need to quickly type in commonly used text snippets and/or other information may have the interface customized to suit their needs, which may enable them to enter information more efficiently. Text fields and/or other input items may also include standard vocabulary sets and/or preset options which may also be searchable.

[0128] FIG. 5 illustrates an example of a text field 502 in a form 500 which displays a macro set of options 504 with options of insertables 505 after an initial input of some text 503. FIG. 5a illustrates an example of a button 502a in a form 500 which displays a macro set of options 504a when the button 502a is pressed, as opposed to requiring some input of information, such as the text 503 in FIG. 5.

[0129] In general, as any given record in the EHR system, such as a patient record, grows over time, certain pieces of information may inevitably be collected over and over again, such as, for example, allergies and active medications. For example, there may be clinical and/or auditability requirements which may require the information to be collected multiple times, which may result in the latest up-to-date information potentially being scattered across multiple documents. For example, a patient may state a certain allergy during one encounter, but forget to mention it at the next encounter.

[0130] In some exemplary embodiments, the EHR system of the present invention may provide a reconciliation capability to allow information collected from the same and/or a related form templates across multiple documents to be presented together and to enable the user to choose which, if any duplicate and/or conflicting entries to keep and which to discard. Unlike in a paper record, the information in the EHR system may be structured and/or identifiable by the EHR system, such as by being keyed as discussed above, such that a search may enable the same and/or related information to be agglomerated easily, as opposed to a paper record where a user must manually sift through all of the applicable forms to retrieve the information. Further, in the paper record, the information may not be easily pulled from the scattering of paper documents onto a single document, as opposed to the EHR system, or information may be missed during review of paper documents during a rushed review or when time is of the essence.

[0131] Also, unlike a paper record, where the only means for organization and/or reorganization are generally re-ordering pages, inserting cover/separator pages, and/or attaching tape flags or the like, electronic records may generally be re-sorted essentially instantaneously to meet the needs of the work being done at the moment. For example, the subset of documents of interest to lab technicians in a patient record may be somewhat different than the subset of interest to, for further example, receptionists admitting patients. In paper form, where the pages cannot be reorganized for one user as opposed to another except by having multiple copies of the same record in various orders which may cause problems in patient care, the present invention allows the subset of documents of interest to one group of users, for example lab technicians, in a patient record may be somewhat different than the subset of interest to, for further example, receptionists admitting patients.

[0132] In an exemplary aspect of the present invention, the EHR system of the present invention may utilize table of contents (TOC) system objects to define a dynamic organization for documents in a patient record. In some embodiments, documents may be dynamically organized by the TOC into a tree structure which may be similar to the standard “folder paradigm” most users of desktop computers are familiar with. For example, unlike the table of contents for paper books and the like, the EHR system of the present invention may utilize TOC definitions which may not be static, such that they may be adapted, for example, on a per-user basis, based on situational needs and/or based on the role(s) of the user (e.g., doctor, lab technician, etc.). The TOC may thus be customized for the particular user and/or the particular needs of a situation, such as to provide an efficient and/or intuitive organizational scheme to navigate through information in documents. Further, the EHR system TOC may operate as a navigational tool, rather than actually governing the manner the information itself is stored within the system, as opposed to common file folder hierarchy-type file systems.

[0133] In some embodiments, the root TOC level may define a menu of choices presented to the user. The menu of choices may further contain a mix of documents, such as, for example, a Basic Patient Information document, reports (e.g. “Blood Pressure Over Time”), and/or links to other TOC levels, which may be similar in appearance and/or usage to sub-menus in a typical desktop application. The menu may typically be defined as a series of queries to the database of the EHR system of the present invention, and the queries may be very specific, such as, for example, “show the patient's one and only Basic Patient Information document”, broad, such as, for example, “show all radiology images for this patient”, and/or any intermediate specificity. Menus may also be typically divided into multiple sections for ease of navigation and may also include buttons and/or other control features that may allow new documents and/or levels of organization to be added. For example, a menu may include a section that lists all radiology images for a particular patient, and a button and/or other control feature may be configured to appear in that section to give the user the option to add information, such as, for example, a new image.

[0134] FIGS. 4 and 4a illustrate a view in the EHR system of a report on a patient 400, which may include, for example, a TOC 410 displaying a hierarchy of documents available for that patient, and a widget(s) for displaying particular information from documents 420, such as, for further example, the photo widget 422 showing the patient's picture and the label widget 424 with a QR code for the patient. Other widgets may also be utilized, such as HTML widgets, as illustrated, for example, with widgets 426, 428 which may be utilized to display vital sign records and heart rate/pulse, respectively, in FIG. 4a. Different items may also be accessible within a TOC, such as forms and reports, as shown with form link 413 and report link 414 in FIG. 4a. A TOC may also contain command items, as shown with command button 411. FIG. 8 also illustrates an example of a form 800 with a variety of widgets, such as, for example, simple text content 801, vocabulary search widget 802 for selecting from a provided list of options, a single choice widget 804 for selecting from several option buttons, a date entry widget 806, and a binary (e.g. yes/no) widget 808. An indicator of which patient being viewed may also be displayed, such as with patient indicator 104.

[0135] In some examples, TOC levels may contain links to other TOC levels, and thus users may choose to view documents along different axes depending on the particular task and/or situation. FIG. 4a illustrates an example of a nested TOC level indicator 412 which may open a TOC sub-level. This flexibility is in direct contrast to a paper system, where physical pieces of paper can only be ordered one way or another, and reordering is time-consuming. For example, by defining a TOC sub-level in the EHR system of the present invention, such as, for example, for patient encounters, and placing links to the patient's different encounters in the root TOC level, clinicians may view the information collected on a patient by encounter. At the same time, for further example, one may also define a different TOC sub-level, such as, for example, for billing accounts, and place links to these accounts in the root TOC level. These links may then provide, for example, billing specialists in the accounting department with a different view into the exact same patient record documents that is more attuned to their needs in a manner that is not possible with a single paper record.

[0136] FIG. 6 illustrates an example of a TOC sub-level 600 accessed from the TOC 410 in FIG. 4. The TOC sub-level 600 may further display links for additional documents/forms which may be useful based on the originating TOC item in TOC 410, as illustrated with the further TOC sub-level items 610 and/or a selected item 620. A back button 612 may also be included to return the user to the higher TOC level. FIG. 6a may further display a TOC sub-level 600′ which may be accessed from the TOC sub-level 600 in FIG. 6 to display additional documents/forms, such as illustrated with additional further TOC sub-level items 610′ and/or a selected item 620′. Similarly, a back button 612′ may also be included to return the user to the higher TOC level. As discussed above, the TOC levels and/or sub-levels may generally display links to documents/forms without affecting the underlying storage of the documents.

[0137] In yet another aspect of the present invention, the system objects utilized by the EHR system of the present invention may generally be treated similarly to other institutional knowledge by an institution and may thus be backed up, versioned, updated in accordance with a defined change process, and/or otherwise treated in a similar manner to other institutional knowledge subject to management.

[0138] In some exemplary embodiments, system objects may generally define virtually every aspect of how users interact with the EHR system of the present invention at their institution. As such, the entire collection of system objects may be backed up, versioned, updated in accordance with a defined change process, etc. For example, at the beginning of an EHR system rollout, an initial version may be produced based on a combination of generic definitions for various items, such as, for example, tables of contents, patient forms, institution-specific customizations for patient admissions and/or lab processes. The next version and/or following versions of the system object collection may then be introduced in various ways to minimize disruption to the continuing operation of the EHR system at the institution. It may be desirable to perform updates on these system objects on a copy or instance of the EHR system of the present invention which may be dedicated to development and testing, and thus separate from the main operating instance being used by the institution. Thus, when the design work and/or other updating is complete and/or approved, the new collection of system objects may be copied to a training instance of the EHR system of the present invention, which may also be separate from the main operating instance, such as to allow the staff and/or other users to become familiar with the new changes without affecting the continuing operation of the main operating instance of the EHR system of the present invention at the institution. After adequate training, debugging and/or other finalization, the system object collection may then be pushed to production servers such that it may become part of mainstream use in the institution in the main operating instance of the EHR system of the present invention.

[0139] In some embodiments, the EHR system of the present invention may provide for managing versions of the system object collection by utilizing a synchronization tool which may facilitate transfer of system object definitions between instances of the EHR system of the present invention, such as, for example, between a development and testing instance, a training instance and the main operating instance. In one embodiment, the synchronization tool may utilize methods of identifying versions of system objects such that there may be minimal ambiguity when synchronizations occur. For example, the synchronization tool may identify different versions and give users the option of copying an updated version of a system object from one instance to another, such as, for example, on an individual basis, or for further example, en masse or as batches.

[0140] In other embodiments, the EHR system of the present invention may provide for managing versions of the system object collection by utilizing standard software development source control practices which may generally treat every system object as a source file that may be checked out and updated from a source control repository. For example, the EHR system of the present invention may utilize, for example, a git repository for the source files of the system objects. Source control may, for example, generally enable larger sets of personnel to work on updates at the same time and/or manage the changes that are introduced by each in a more systematic fashion. For further example, standard software development source control practices may also employ well-established best practices for backing up and maintaining repositories, such as git, that may be implemented to safeguard system objects utilized by an institution.

[0141] In some exemplary embodiments, the EHR system of the present invention may further include features for modifying and/or customizing system objects which may be accessible directly from the user interface on a device. This may be desirable as forms, templates, and/or other system object components of the EHR system of the present invention may be modified and/or customized on the fly instead of being wholly dependent on time-delayed development and/or customization. For example, customization may thus occur on-site and/or during the course of using the EHR system of the present invention rather than waiting for long development/update cycles to occur. In some embodiments, system objects may be created and/or edited using a subset of YAML syntax directly from within the user interface of the EHR system of the present invention.

[0142] FIGS. 7 and 7a illustrate examples of a system object editor 700 accessible from the user interface of the EHR system of the present invention, which may include, for further example, a listing of existing system objects 710, which may be selected for editing, such as shown with selected system object 711 being displayed in the editing widget 720. A user may then edit the definition, such as with YAML syntax as illustrated with the system object definition 721, showing, for example, a definition for basic patient information template in FIG. 7 and a definition for a smoking/alcohol status template in FIG. 7a. Additional editing tools, such as specific syntax buttons 730 may also be provided.

[0143] In another aspect of the present invention, the EHR system of the present invention may utilize workflows to facilitate and/or conduct the review and/or approval of documents by a set of users.

[0144] In some embodiments, work queues may be utilized and may include a list of documents that have been posted for consumption, review and/or approval by a recipient, in a similar manner to an inbox of an email application. In general, the EHR system of the present invention may provide a work queue for each user and/or a single work queue for each group of users, as illustrated with the approval queue 160 in FIG. 1a. The EHR system user interface may further include a dashboard where users may view the lists of documents that have been posted to their own work queues and/or the work queues of any groups to which they belong.

[0145] FIG. 2 illustrates a work queue view 200 accessible from the work queue button 112. The work queue view 200 may generally display a listing 210 of items for review and/or approval by the user, and each individual item may be viewed by selecting, such as illustrated with the selected item 220. The selected item 220 may further include additional controls 222, such as a button to submit an order, view the status of the order in the workflow, and/or show additional options, as illustrated.

[0146] In general, posting a document to a work queue may not remove it from anywhere else in the EHR system of the present invention, such as, for example, from the patient record and/or other accessible location, but rather work queues may merely contain links to the documents that have been posted to them. For further example, when a document is removed from a work queue, in general only the link may be deleted from the queue while the underlying document is not affected or deleted. In this manner, the EHR system of the present invention may take advantage of an electronic system, such as with document check-in and check-out features, which may enable the EHR system f the present invention to preserve the underlying documents in a central storage while enabling them to be linked, visible and/or otherwise accessed from various parts of the EHR system of the present invention without creating conflicts.

[0147] In some embodiments, the documents in a work queue and/or workflow may require review and/or approval by certain users, such as, for example, before the documents may progress in the workflow. In one embodiment, the documents in the workflow may be signed by appropriate users to continue the workflow. In one embodiment, a document may be said to have completed its workflow if signatures are collected from all necessary users and/or parties. The list of necessary users and/or parties may be determined based on the workflow steps. FIG. 2 illustrates the display of a necessary signature 224 for an order in a workflow item 220.

[0148] In general, signatures may be digital signatures or manual signatures. A digital signature may be created, for example, by using a public/private key pair that may be generated for each user when he/she signs a form for the first time and may further be protected by a password or other encryption key, which may be utilized as the user's signing password. Digital signatures in the EHR system of the present invention may use, for example, a hash of the HSD, for example JSON property values visible to the user on the form, which may be desirable to enable auditors to confirm that the signature is authentic and/or that the signature corresponds to the data shown on the screen at the time of the signature.

[0149] A manual signature may also be utilized, and may essentially be a piece of human-readable evidence that may generally take the form of a traditional written signature, which may also be given a visual representation in the user interface of the EHR system of the present invention. Manual signatures may be stored, for example, in a property of the document that is declared to the workflow system using a property of the template for the document. Unlike a digital signature, a manual signature may generally not be authenticated by the EHR system per se and the EHR system may therefore, for example, require the user to attest that the manual signature has been captured properly on behalf of an authorized submitter as part of, for further example, auditability.

[0150] The submitter of a document in a workflow may generally be the user who initiates a particular workflow process; however, the submitter may not necessarily be the same as the person who submits the document at the end of a step in the workflow. For example, many institutions allow for telephone orders and/or orders received by fax or other paper-based means, and thus the person submitting a document may be acting on behalf of the actual submitter of the document, such as, for example, a physician, which in the case of an order may be the only type of user authorized to legally submit an order.

[0151] In some embodiments, submissions in a workflow may be restricted in the EHR system of the present invention such that only authorized and/or proper users may submit. For example, if a user does not belong to one of the specified user classes in the EHR system of the present invention, the EHR system may prompt the user to specify which user on whose behalf the form and/or other workflow item is being submitted. In this manner, for example, a user may enter a telephone, fax and/or other remote order, which may cause the EHR system of the present invention to start the workflow as if the authorized user had already signed and/or also in parallel (i.e., not obstructing the normal workflow) place the document into the queue of the authorized user to do a final signoff. In embodiments using a manual signature, the EHR system may create a digital signature based on, for example, the public/private key pair of the user that actually entering the submission, while also incorporating the identifying information of the user on whose behalf the submission is actually being made.

[0152] In general, the steps of a workflow may specify the order in which signatures and/or other authorizations are to be collected. A step may either specify a particular user and/or a group of users that indicates the kind of signature that may be needed to complete a step. For example, if a step specifies a particular user, the step is considered complete if the document has collected that user's signature. For further example, for a step specifying group of users, a signature from any user in that group may be sufficient. Thus, the EHR system of the present invention may examine the workflow steps sequentially to find the first step that has not been completed when submissions are made in the workflow. The particular user and/or group of users of that step may further determine the particular work queue into which the document is placed. Thus when all steps are completed, the document may be placed in the completed queue, such as may be defined by the template of the document.

[0153] Notes may also be incorporated into the various steps of the workflow, such as, for example, to enable users to annotate and/or comment as the workflow progresses. A notes widget may be included in a form by the template such that notes may be easily added from the user interface of the EHR system. As illustrated in FIG. 2, notes 226 may be displayed for the workflow item 220.

Example of TOC Functionality

[0154] In one example, when a user first opens a patient record, a TOC level is presented on the left hand side of the EHR system. Every TOC level acts in fundamentally the same way: a TOC level is focused on a single document (in this case, the patient document) and displays a list of documents that result from a database query defined by the tocLevel document (queryExpression property). The UI for this list is broken down into sections that are defined by config documents. There may be multiple config documents and a subset of these will apply to the current situation because they contain a tocLevelID property that corresponds to the active TOC level and a list of groups under the targetGroupIDs property that can be matched against the current user's group membership. When a TOC level is loaded, the UI automatically queries for all matching config documents and composes the sections defined therein into a single list. The sections in the config documents (listed under the sections property) act to filter documents that were returned by the database query mentioned above.

Example of Querying for Documents to Appear in a TOC Level

[0155] The tocLevel document may contain a queryExpression property whose string value is expected to be a JavaScript expression that, when evaluated, should yield a JSON object that is to be passed to “MongoDB” to perform a database query. Within this JavaScript expression, some commonly-used expressions include:

[0156] 1) context.document refers to the document the TOC level is focused on

[0157] 2) context.document._id refers to the ID of the document the TOC level is focused on

[0158] It is also common to structure the queryExpression as follows:

[0159] queryExpression:| [0160] jsonExpression={ . . . }

[0161] The reason for starting the expression with jsonExpression=is to take advantage of the JSON syntax built into JavaScript for constructing the query object, which is only available for expressions on the right hand side of the assignment (=) operator.

[0162] When the user selects a document listed in a section under a TOC level, one of several actions can be defined to take place. If the document is set up to trigger a navigation to a deeper TOC level, the UI “pushes” the current TOC level onto the navigation stack and the new TOC level is displayed. (By “push” we are referring to the fact that a “Back” button appears to allow “popping” back to the old TOC level.) The focus document of this new TOC level will be determined by how the navigation trigger to the TOC level is set up. If the document is not set up to trigger a TOC level navigation, then it will be opened on the right hand pane.

[0163] The TOC level also allows users to create new documents. As with document selection, document creation can also be set up to not create a user-editable document on the right hand pane per se but instead to create a document whose main purpose is to act as a container for other documents and trigger navigation to a deeper TOC level. “Encounters” and “billing accounts” are examples of such container documents.

Example of Defining Sections in a TOC

[0164] As mentioned above, sections are defined by the sections property of config documents. An individual section in the sections array has an items property that specifies the order of the menu items that appear under that section. Each item in the items array is assumed to be a document ID. The type of the corresponding document determines the behavior of the corresponding menu item(s) displayed: [0165] 1) An ID of a template document instructs the UI to display the documents created from that template. [0166] 2) An ID of a tocLevel document instructs the UI to display a reference to this TOC level which, when pressed, triggers navigation to that TOC level but with the same focus document as the current TOC level. This option is useful if the child TOC level is to display a subset of the documents from the current TOC level. [0167] 3) An ID of a report document instructs the UI to display a reference to this report which, when pressed, displays the report on the right hand pane with the same focus document as the current TOC level.

Examples of Workflow:

[0168] In one aspect, an example of an example of work flow with just workflow steps in healthcare area may be a workflow for an X-ray order as follows: [0169] 1. a doctor fills in an X-ray order form [0170] 2. a doctor signs the X-ray order form (the need for the doctor's signature is defined in the workflow steps built into the X-ray order form layout) [0171] 3. the X-ray order is routed to the radiology technician queue to notify the technician to prepare to do the order needed for the patient (the final destination for the form radiology is defined in the workflow steps built into the X-ray order form layout).

[0172] In another aspect, an example of workflow with just a modal process in the healthcare area may be a workflow for registering a patient for a lab visit, as follows: [0173] 1. the check in desk attendant asks the patient for ID [0174] 2. the attendant locates the patient's record in the EHR based on last name and date of birth [0175] 3. the attendant taps a button on the mobile device to bring up a modal process that dynamically generates a form to confirm the patient's lab appointment details (time, specific kind of lab, etc.) and generates a barcode label bracelet to be printed.

[0176] In a further aspect, an example of workflow that includes both the modal process and workflow steps in the healthcare area may be a workflow for a prescription order, as follows: [0177] 1. a doctor fills in a medication order form [0178] 2. a doctor signs the medication order form (the need for the doctor's signature is defined in the workflow steps built into the medication order form layout) [0179] 3. the medication order is routed to the pharmacists' queue (the second approver—pharmacy—is defined in the workflow steps built into the medication order form layout) [0180] 4. the pharmacist uses a modal process specifically designed to show him/her the medication order alongside the patient's current medications and allergies on a form dynamically generated by the modal process [0181] 5. later on, the pharmacist uses a modal process specifically designed to dynamically generate a form showing upcoming doses that need to be dispensed (called the “fill list”), and he/she dispenses the medication dose that is needed [0182] 6. the nurse then takes that medication dose and uses another modal process specifically designed to show a form prompting the nurse to confirm the date, time, quantity, route, and drug substance and then to ask for the nurse's signature when the dose has been administered.

[0183] It will be appreciated by those of ordinary skill in the art that the present invention can be embodied in other specific forms without departing from the spirit or essential character hereof. The present description is therefore considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the appended claims, and all changes that come within the meaning and range of equivalents thereof are intended to be embraced therein.