WO2018201182A1 - Method, system and apparatus for the management of a clinical workflow - Google Patents

Abstract

The present invention provides in one form, a clinical workflow management system comprising a web based user interface comprising a single page application for displaying at least one clinical workflow; at least one application programming interface comprising a REST compliant set of stateless operations, where the at least one application programming interface operates between the web based user interface and at least one data store; and, a scalable data storage base comprising the at least one data store; wherein the web based user interface is operatively associated with the scalable data storage base through a set of bounded contexts where each bounded context is associated with one of the application programming interfaces and one data store

Description

METHOD, SYSTEM AND APPARATUS FOR THE MANAGEMENT OF A CLINICAL WORKFLOW

RELATED APPLICATIONS

[001 ] This application claims priority to Australian Provisional Patent Application No. 2017901579 in the name of Health Communication Network Pty Limited, which was filed on 1 May 2017, entitled "Method, System and Apparatus for the Management of a Clinical Workflow" and the specification thereof is incorporated herein by reference in its entirety and for all purposes.

FIELD OF INVENTION

[002] The present invention relates to the field of clinical services. It will be convenient to hereinafter describe the invention in relation to the management of clinical workflows of general practitioners and/or specialists within medical practices, however it should be appreciated that the present invention is not limited to that use, only.

BACKGROUND ART

[003] Throughout this specification, the use of the word "inventor" in singular form may be taken as reference to one (singular) inventor or more than one (plural) inventor of the present invention.

[004] It is to be appreciated that any discussion of documents, devices, acts or knowledge in this specification is included to explain the context of the present invention. Further, the discussion throughout this specification comes about due to the realisation of the inventor and/or the identification of certain related art problems by the inventor. Moreover, any discussion of material such as documents, devices, acts or knowledge in this specification is included to explain the context of the invention in terms of the inventor's knowledge and experience and, accordingly, any such discussion should not be taken as an admission that any of the material forms part of the prior art base or the common general knowledge in the relevant art in Australia, or elsewhere, on or before the priority date of the disclosure and claims herein.

[005] Clinical and practice management applications are by and large becoming the main systems used within medical practices, particularly for professional clinical services providers such as general practitioners and/or specialists within medical practices. As such they can have a large impact on efficiency and clinical effectiveness. Research has showed that clinicians may spend more than 50% of the average medical consultation interacting with the clinical management system. This may result in two detrimental effects, as follows:

1 . Limiting patient care - The clinician may be more focused on the system and not the patient. Accordingly, time could be better spent on patient care; and,

2. Lost productivity - Clinician time is a key limiting factor in the efficiency of a medical practice. Accordingly, time spent interacting with the system limits productivity of the practice.

[006] A review by the inventor of software packages utilised in Australia, and internationally, indicated that the above noted problems had not been solved effectively in practice. It is considered that, universally, prior art systems have applied software processing and interfacing techniques of Tree control, Modal control and Tab implementations with multiple windows and tabs using known interface/design patterns. With respect to the Australian market, software packages such as Medical Director™, Clinical™, Pracsoft™, Best Practice™, Genie™, Medtech32™ and more recently MediRecords™ all exhibit the traits mentioned above. With respect to international markets, in particular, in the USA; a survey of the top 20 EHR (Electronic Health Records) vendors such as Epic Systems, Allscripts, NextGen, GE Healthcare, Cerner, Athena Health, McKesson, E-MDS and others, also indicated that tabs and tree controls and modal dialogs were prevalent. These prior art systems can complete workflows but fail in efficiency. The methods of implementation used by these vendors, especially for the clinical workflow; forces users to constantly navigate away from the different dimensions of information required to complete the workflow. This is inefficient because the interactions are not streamlined and context can be lost.

[007] US patent application publication No. 2009/0094529 in the name of Gonzalez et al and assigned to General Electric Company (hereafter referred to as Gonzalez) discloses a method and system for context sensitive workflow management in clinical information systems. Gonzalez aims to provide clinical display and search capabilities for all of a patient's electronic medical record data from a variety of disparate information systems, see paragraph [0004] of Gonzalez, for example. Gonzalez identifies a number of problems with existing systems at paragraphs [0006] and [0007] describing existing data and records management with various information systems such as HIS, RIS, CIS, CVIS along with storage systems such as PACS, LIS and EMR. In particular, it states that in a conventional clinical application, a single workflow (such as discharging a patient from an emergency room) might involve a user executing multiple tasks. Execution of multiple tasks often requires the user to navigate to several different parts of the application in order to perform each step of that workflow and this navigation can be difficult and tedious for a user that is not sure where to go in an application and perform multiple tasks. Further, Gonzalez notes it can be difficult for multiple users to visualize which tasks have been completed already, and which ones remain to effectively coordinate their efforts. Overall, Gonzalez states that existing clinical information systems have incorporated features that try to improve usability of these complex systems. For example, to-do lists, clinical decision support, and workflow engines have been implemented to help automate some of the work that needs to be accomplished during the execution of complex workflows. In summary, Gonzalez says that no product, to date, has combined these features into a user-centric workflow management system. However, the solution provided by Gonzalez merely provides a web enabled user interface that provides hyperlinks where a user selecting a link triggers a connection or access to one or more "external actors", which in the context of Gonzalez, are such as opening an application, accessing a clinical system, populating data, and/or producing an output, for example, see paragraphs [0026], [0057] and [0058]. Paragraph [0026] continues by stating a user may select a plurality of links for the workflow within a single user interface (described as a 'unified user interface'), thus avoiding multiple logins for multiple systems, or use of a plurality of interfaces to execute a single workflow, etc. Additionally, multiple users may be given access to the task list via the interface such that different users may execute different actions within the workflow. In certain embodiments, links to already-executed tasks may be represented differently from links to not-yet-executed tasks such that a user may visually discern which actions have been executed and which have not. In certain embodiments, multiple users may simultaneously execute tasks via the interface from different workstations. In other embodiments, multiple users may access the interface in sequence, with actions taken by prior users stored for reference by later users, for example. Practical implementation of the solution of patient data points being aggregated into a single location provided by Gonzalez comes from the capabilities of a unified user interface with a rules-based context manager and is reliant on the export capability of the plurality of separate clinical applications to allow aggregation and storage of information to a single locale. At paragraph [0038], Gonzalez states the unified user interface interacts with individual interfaces for the external application(s) and/or system(s) and masks or hides the individual interfaces from a user. That is, the user sees and interacts with the unified user interface rather than the underlying individual interfaces. However, Gonzalez does not provide any substantial reduction to practice of the aggregated information system it describes. Essentially, Gonzalez is an attempt to create efficiencies within disparate hospital systems where, inter alia, integration between platforms is required. This approach will again force the user to navigate between systems and then the user experience is limited by the interface applied to these disparate systems.

[008] US patent application publication No. 2008/0098327 in the name of Berkovitz et al (hereafter referred to as Berkovitz) discloses a user interface for providing an information gateway between a user and one or more applications running on a computer platform with techniques for presenting information acquired from a user during an interactive session in the form of a summarised accordion view. At paragraphs [0006] to [0008], Berkovitz describes problems with existing user interfaces in the context of e- commerce where there is the possibility of a consumer getting confused or lost while navigating the sequence of views. If the user interface presents only one view at a time, the consumer may forget what information has already been entered in a previous view. Or, if the consumer does not have a particular piece of information handy when the user interface solicits that information, the consumer may skip to another view expecting to retrieve the missing information later. In this case, the consumer may have difficulty navigating back to the view with the missing information, resulting in a frustrating experience. Thus according to Berkovitz, in general, existing user interfaces have deficiencies that make transactions confusing or frustrating. For example, some existing user interfaces include windows that do not provide data entry capabilities at all. These windows merely provide static content. As another example, some interfaces do not provide significant feedback regarding the content of a particular window once that window has been completed and closed or minimized. These windows may provide a title, but do not give the user insight as to specific content of the window. Whenever a consumer encounters confusion or frustration during a transaction, that consumer may simply decide to abandon the transaction. A consumer is more likely to complete a transaction if the user interface provides a pleasant experience by reducing or eliminating any perplexing or annoying situations. The solution Berkovitz provides to address these problems is a user interface for providing an information gateway between a user and a computer platform which includes two or more windows for displaying information, and for facilitating information entry from a user. The size and/or shape of each of the windows changes as the window content changes. The user interface requires the user sequentially step through the windows, completing the required data entry for each window before proceeding to the subsequent window. As the user encounters a particular window, that window expands to display details of the window content. When the user completes the data entry fields of an expanded window and proceeds to the subsequent window, the completed window collapses to display a summary of the content. In summary, Berkovitz is restricted to sequential access to windows in which the user must complete at least one predetermined data entry task before accessing a subsequent window and it is a simple generic solution to a basic multi-step process and does not address any of the contextual nature and workflow requirements of a clinical system.

[009] US patent application publication No. 2008/0208631 in the name of Morita et al and assigned to General Electric Company (hereafter referred to as Morita) discloses a user interface and method for aggregating and displaying clinical documentation of a patient lifetime. Morita relates to healthcare facilities that must manage a plurality of patients, systems, and tasks to provide service to patients and the problems healthcare personnel encounter in their workflows. At paragraphs [0004] and [0005] Morita notes that different clinical departments and different clinical systems gather patient information in different ways and in different forms and often separately stores that information and with a need for the information to then be retrieved and viewed from several disparate systems there is the problem that existing information and management systems do not offer interconnection and flexibility. In particular, at paragraph [0006], Morita notes that relevant patient information for a patient's entire lifetime exists in a number of formats that include paper, folders and disparate information systems from a variety of vendors and a variety of healthcare providers and current systems cannot aggregate this information effectively. Additionally, current systems cannot display this information at one time so that healthcare providers can interpret a patient's complete medical history when assessing and diagnosing illnesses and, as such, providers are rarely able to see the full history of a patient. More commonly, providers have only the information that they have gathered or that they have received in response to questions asked of the patient in a clinical setting. Key decisions are therefore made with the limited knowledge available to the provider at the point at which the provider is making a decision. Morita makes particular reference to the deficiencies of the LifeLines™ prototype at the University of Maryland, which represents an electronic medical record as a series of timelines. However, the LifeLines™ system lists high-level information for pattern visualization and to drill down to granular information, such as liver panel or white blood count, a user of the LifeLines™ application must click on a graphical icon that opens a preview panel to a separate file or structure containing this information. The granular information is not embedded into the interface but is rather stored and displayed separately. Opening a preview window also causes the timeline to compress, so the viewer loses some of the high-level context of the initial navigation when reviewing granular information. Accordingly, loss of high level content may create confusion and frustration for users. Morita provides a solution in which a user interface system displaying an electronic patient record includes a timeline representation of a patient record. The timeline includes a plurality of data points related to a patient over time. The plurality of data points provides patient data aggregated from a plurality of information sources. The timeline provides access to and review of the plurality of data points within a single view. The system includes one or more controls allowing navigation and manipulation of one or more of the plurality of data points in the timeline. As with Gonzalez discussed above, Morita relies on export capability from a plurality of clinical applications to provide aggregation and storage of information to a single locale and also relies on a clinical context manager and/or other rules based context manager to provide the aggregated interface. Morita also provides for a user to navigate, manipulate and view different information and different levels/granularity of information in the interface by dragging, scrolling and/or otherwise moving a viewpoint via mouse and cursor, keyboard, trackball, touch screen, etc. At higher magnification, greater details of the patient start becoming clearer. Based on particular events or problems, the user may choose to zoom in further for greater detail. Further magnification allows greater detail for a particular patient event or source of information. Information displayed may have hyperlinks attached to allow the user to navigate to an information system that initially generated the data to drill down on finer details. Alternatively and/or in addition, finer details related to the information may be present in the patient history context and become viewable and reviewable as the user drills down into the timeline. It is considered that the context sharing of Morita is reference to configuration settings, options and information being shared between application systems. Morita covers some generic patient workflows and for the user it provides a timeline that moves from left to right and contains fixed sections. Based on the disclosure at paragraph [0104] of Morita, the rules seem to refer to criteria to filter data or an event based on date or types or grouping of types. There is no further information provided about the implementation of these rules and so is somewhat difficult to assess. At least one limitation is that the rules need to be defined by a system user.

[010] US patent application publication No. 2015/0317435 in the name of Klocek et al and assigned to Practice Fusion, Inc. (hereafter referred to as Klocek) discloses a method of presenting a patient's disparate medical data on a unified timeline. Klocek highlights existing problems with paper-based medical records and also discusses problems with electronic medical records in as much as their high implementation costs but at paragraph [0016] also highlights the problem that, like paper-based records, standard electronic health records also segregate different types of information into different views and just as a paper file segregates notes on patient encounters and lab results in different areas, an electronic health records interface typically presents these different types of data in different tabs and to get a complete picture of patient care, a physician has to switch between the different views by, for example, switching between different tabs. Summarised at paragraph [0017], Klocek provides a solution in the form of a method in which a request for medical data related to a patient is received. Then, data records in a medical records database that relate to the patient are identified. The medical records database includes a plurality of different types of medical data records, and each data record is associated with a corresponding time. According to the data records' corresponding time, the identified data records are temporally ordered to generate a timeline. Finally, the timeline is output to a device for display, such that the displayed timeline presents the plurality of different types of data records related to the patient together in a single temporal view. There is no filtering provided and the timeline of Klocek is in one dimension. It is considered that Klocek does not allow for contextual filtering and does not address any of the workflow productivity issues noted above.

[01 1 ] US patent application publication No. 2010/0131434 in the name of Magent et al and assigned to Air Products and Chemicals, Inc. (hereafter referred to as Magent) discloses an automatic system and method for analysing, and presenting an integrated view of a patient's health status to clinicians. Magent addresses the problem of despite there being high-tech medical systems, and electronic-medical-record systems, many healthcare providers continue to collect and record data in paper format, which are often maintained in chronological order and, in a time-stressed environment, the clinician may fail to appreciate trends or recognize subtle changes in a patient's health using this hodgepodge of electronic and paper records. Furthermore, at paragraph [007], Magent notes also that, when a patient leaves the clinician's office, rarely does the clinician have the time or resources to follow-up with the patient to track and monitor the patient's condition. So, the conventional methodology of waiting for a patient to contact the healthcare provider when a health episode occurs appears to be the way in which most healthcare providers treat patients regardless of whether the health records are in electronic format or centralized. According to Magent, managing, and providing health care to patients today remains largely reactionary, inconsistent, and costly. Magent provides a solution to these problems by way of a system, which automatically collects and analyses historic-physiologic data indicative of a patient's health from a myriad of sources, and based on the historic-physiologic data, the system automatically generates a health-risk score indicative of whether a patient will experience a serious-medical event in the near future. In particular, the system of Magent uses a processing model that may rely on Hierarchical-Temporal Memory techniques and other models, for extracting and analysing patient data. The system also generates an integrated synopsis of a patient's health condition, including the health-risk score. The synopsis is then presented (served) to a clinician in an organized, simplified, and effective manner via a client-side user interface. The synopsis enables a physician to proficiently grasp the patient's most critical health parameters in a short period of time. Effectively, Magent is directed to providing a predictive assessment of a patient requiring health services in a predetermined 'near future' time interval but does not address the problems identified in relation to efficiency and productivity when completing workflows.

[012] International (PCT) patent application publication No. WO 02/075612 in the name of Specialist Information Services Pty Ltd (hereafter referred to as Specialist Information) discloses a computer implemented system for professional management of medical specialists functioning in a multi-site environment. The system of Specialist Services is merely the computer assisted implementation of managerial and administrative functions of a medical practice that are performed on a computer data network platform, which envisages the utilisation of relevant computer data network hardware and software as would be available to the person skilled in the art on or around the priority date of this disclosure. [013] Granted US patent No. 9,052,809 in the name of Vesto and assigned to General Electric Company (hereafter referred to as Vesto) discloses a system and method for clinical event processing with situational awareness to dynamically facilitate a clinician's workflow in the event of dramatic variation in clinical demand of medical services. Vesto discusses the problems facing hospitals and clinics with pressure to deliver high quality patient care, prevent adverse events/errors, and implement clinical best practices while reducing the cost of healthcare delivery. In particular, where hospitals can face dramatic variation in clinical demand and are increasingly likely to be declined reimbursement when patient care falls short. Hospitals that operate at or over capacity may experience heightened rates of safety events. According to Vesto, current systems support is provided based on anticipated, static events, and do not account for chaos and unpredictability associated with many medical events. In particular, Vesto notes that many state-of-the-art Clinical Information Systems can provide the alerting, clinical decision support and best practice guidance, which can result in better outcome and improved healthcare delivery, however, more often these applications are built where events are anticipated and planned for while healthcare delivery can at times be chaotic. In essence, Vesto notes at column 3, lines 14 to 17 that the clinicians' time to interact with IT systems is limited especially under periods of stress. They need access to the right information and the right tool at the right time. The solution provided by Vesto is the described Clinical Event Processing and Situational Awareness platform which utilises "Complex Event Processing" and comprises a situationally aware computer- implemented method for deploying clinical applications, the method comprising: receiving information regarding a clinical event from an event source; processing, using a processor, the information regarding the clinical event to determine a clinical situation based on the clinical event, the processing including single event processing of the clinical event and complex series event processing of the clinical event and an event history associated with the clinical event to determine the clinical situation; adding, using the processor, a clinical context to establish an enriched information regarding the clinical event; identifying, automatically using the processor, a next anticipated clinical application based on the enriched information regarding the clinical event and the determined clinical situation, the next anticipated clinical application automatically determined for use by a healthcare provider and automatically configured based on the enriched information regarding the clinical event and the determined clinical situation; and providing the next anticipated clinical application to the healthcare provider on a device associated with the healthcare provider in anticipation of a clinical workflow involving the clinical situation to treat a patient. Vesto provides an enhanced user experience by its ability to anticipate varied demand on the system but much like Magent, it does not address the problems identified in relation to efficiency and productivity when completing workflows. Vesto focuses on the processing of clinical events in a hospital setting. As an event is received the system of Vesto will start the relevant application ready for a clinician to process and complete a workflow. The applications are all separate with little or no ability to look at data from multiple applications in context. In this respect, it is noted that the general practice setting is different to a hospital where a patient would present, key health summary information is captured and a broad range of issues and actions would be completed within a single consult. Specifically, Vesto falls short in as much as it does not address the following problems: (1 ) Limiting patient care. The display of portions of a patient record that are contextually relevant to what is currently being viewed by a clinician. Vesto talks about handling events and providing contextual information such as patient location in the hospital then starting a relevant App to complete one specific workflow such as reviewing. This does not solve the problem of displaying all contextually relevant information within the one user interface; (2) Lost Productivity in a General Practice or outpatient context. Vesto's system has the potential to improve productivity in a hospital setting improving the processing of specific events. This approach is less applicable in the GP or outpatient setting.

[014] International (PCT) patent application publication No. WO 2016/025995 in the name of Whiteboard Pty Ltd (hereafter referred to as Whiteboard) discloses a system and method for access management of medical records. Under the heading "Background to the Invention'' Whiteboard discusses problems with existing e-health solutions. In particular, their failure to provide security and control over confidential information. For example, past approaches which relied on the patient to be the custodian and curator of their own medical information created barriers to effective treatment, rather than benefits, because patients are not qualified to decide what should and should not be included within their medical records. Whiteboard then adds that, as the primary healthcare provider, the GP is the logical person to act as custodian and curator of patient medical records and, as such, computerised health records systems, deployed within general practices, could be an effective platform for enabling GPs to take on this role. However, it is recognised that GPs have limited time available, and therefore any successful medical record management system which places the GP in the role of curator must make the process as simple and efficient as possible. Whiteboard then has the objective of providing a system for the management of electronic health records (EHR) which provide for collaboration and sharing of patient medical information in a manner which is both sufficiently secure, and sufficiently simple and efficient to use, to facilitate its widespread acceptance and adoption by patients, doctors and other healthcare professionals. The solution of Whiteboard includes providing a database configured to contain records comprising at least: an electronic health record (EHR) of the patient which is associated with one or more EHR sub-records; a plurality of health service provider records; and at least one health service network associated with the patient EHR, which comprises one or more health service providers corresponding with said health service provider records, wherein each EHR sub-record is associated with an access control structure defining access permissions granted to health service providers in the health service network, then upon receiving a request for access to an EHR sub- record of the patient; identifying a health service provider record corresponding with a source of the request for access; interrogating the access control structure associated with the EHR sub-record to determine an access permission of the health service provider associated with the identified health service provider record; and providing access to the requested EHR sub-record in the event that a required access permission is granted. Whiteboard is focused on the curation and access to a patients EHR. It does not specifically address the following: (1 ) Limiting patient care. While Whiteboard provides scope for a patient or other clinician to access an electronic health record it does not address providing contextually relevant patient information. (2) Lost clinician productivity. Whiteboard makes no attempt to improve clinician productivity.

[015] EP 1673710, which is equivalent to international patent application publication No. WO 2005/038691 in the name of Siemens Medical Solutions Health Services Corporation (hereafter referred to as Siemens) discloses a medical information user interface and task management system. Siemens addresses problems with computer information systems for clinical applications, which it says typically differentiate between browsing and content. In this respect, after a user of a clinical system uses a browser to navigate through a hierarchical data tree structure, the clinical system permits the user to select and work with a single type of data or tool. Permitted selections include pending or current elements for a patient, adding an element, browsing or any other type of catalog access tool for that same type of data, or to manage the current task with whatever functions are required. One problem is that users typically select a different task and lose sight and context of the previously operated data. Siemens also states that clinical systems typically generate a data-driven model of data and tools. Another problem is that the representations of data with the clinical system are unlikely to match a user's mental model (e. g., workflow process) when: different data is observed, complex professional thinking is involved, and insight is derived from the exclusion of a possible data combination in a way that is unforeseen by the system. More particularly, Siemens states that present clinical systems display medical data by category, then subcategory etc., each by time, but do not display combinations of data that reside in different areas of the data tree to provide insight into patient circumstances or clinical necessity that can lead to appropriate clinical decisions. This type of clinical system causes a user to either make notes, keep multiple instances of the clinical system open at the same time, or to rely on short-term memory to compare and relate information that have been categorized as distinct types of data or tools. For example, looking up current instances of a data type and the initiation of a new type of data or activity for a patient logically have a lot in common, but they are not always related in a clinical workflow. Two adjacent steps of the workflow often touch on different tools and types of data, and the user often needs information from one step when utilizing another step. Siemens provide a solution to these problems by providing an interface processor and a display processor. The interface processor receives information identifying a particular patient. The display processor initiates generation of data representing a composite display image including a first area, a second area, and a third area. The first area includes a first set of data items representing different types of healthcare information, and a second set of data items individually associated with corresponding items of the first set of data items. The display processor initiates generation of data representing a particular type of healthcare information for the particular patient in the second area in response to user selection of an individual item of the first set of data items. The display processor initiates generation of data representing current healthcare information of a particular type for the particular patient in the third area in response to user selection of an individual item of the second set of data items. In general, it is considered that Siemens does not address the two key problems lost productivity and limiting patient care. Siemens cannot display portions of a patient record that are contextually relevant to what is currently being viewed by a clinician. Siemens uses context in the form of the Patient Identifier and User Identifier information to access additional information about a patient but, inter alia, does not filter any elements within those records to items that are contextually relevant. Siemens is not able to display what is required to complete a clinical workflow without the use of tree views, modal, tabbed dialogs. Specifically, with respect to the use of drug interactions warnings, Siemens only has the ability to provide alerts related to batch processes eg pending jobs, overdue, signature missing, conflict etc. Siemens appears to be user initiated query based in nature and can't provide for dynamic updates from multiple concurrent users. Siemens mentions a data repository but provides no further information. Accordingly, there is no provision for data storage of a complex eHealth business domain.

[016] US patent application publication No. 2016/0147946 in the name of Von Reden (Assigned to General Electric Company) discloses a system, apparatus and method to facilitate analysis, presentation, and comparison of clinical information. The disclosed system includes a processor configured to provide a patient library interface. The interface displays a plurality of events along a patient timeline and a list of items for comparison to a clinical scenario. The scenario is specified in an interface configuration to trigger collection of the list of comparison items. The processor receives and adds items to the list based on a relevancy analysis of each item to the clinical scenario. The processor facilitates feedback to add, remove, and rate relevance of item(s) in the list. The processor displays item(s) from the list in conjunction with documentation from the clinical scenario and facilitates user interaction with the item(s) and documentation. The processor updates a data source based on the user feedback and user interaction.

[017] US patent application publication No. 2014/0278525 in the name Curran (Assigned to McKesson Financial Holdings) discloses a method, apparatus and computer program product to provide improved searching of medical records. In this regard, the method, apparatus, and computer program product provide a network infrastructure that gathers search analytics for medical records searches performed across a plurality of record keepers. Correlations are identified between querying record keepers and record keepers that provide records that are properly responsive to queries from the querying record keeper. For example, embodiments may derive search analytics related to which record keepers typically provide correct record results in response to a query from a particular record keeper, and these identified record keepers may be specifically queried in response to future requests received from the querying record keeper. [018] International patent application publication No. WO 2017/042396 in the name of F. Hoffmann-La Roche AG et al discloses an informatics platform which provides an architecture to integrate information from relevant patient information systems. The informatics platform includes: a workflow tool that can be used to prepare and review information at multi-disciplinary board meetings; a visual timeline of patient events; a search engine to search for patients with specific attributes; a graphing tool that can display disparate clinical variables in a single chart; a virtual Pin Board for users to identify relevant patient information for board meetings; an image viewing application that can provide for comparison of images from different information systems; structured reporting functionality that incorporates system aggregated patient information and board recommendations; an application interface that integrates clinically relevant tools to provide patient specific references; a collaboration interface that facilitates communication of patient specific information and documents the discussion threads as independent reference points; and a default display of relevant patient information customized for each clinical specialty.

[019] The preceding discussion of the background art is intended to facilitate an understanding of the present invention only. The discussion is not an acknowledgement or admission that any of the material referred to is or was part of the common general knowledge as at the priority date of the present application.

SUMMARY OF INVENTION

[020] It is an object of the embodiments described herein to overcome or alleviate at least one of the above noted drawbacks of related art systems or to at least provide a useful alternative to related art systems.

[021 ] In a first aspect of embodiments described herein there is provided a clinical workflow management system comprising: a web based user interface comprising a single page application for displaying at least one clinical workflow; at least one application programming interface comprising a REST compliant set of stateless operations, where the at least one application programming interface operates between the web based user interface and at least one data store; and, a scalable data storage base comprising the at least one data store; wherein the web based user interface is operatively associated with the scalable data storage base through a set of bounded contexts where each bounded context is associated with one of the application programming interfaces and one data store.

[022] In a further aspect of embodiments of the invention described herein there is provided a method of operating a clinical workflow management system comprising one or a combination of the following steps: associating each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores with a separate one of a plurality of bounded contexts; sending system requests in order of importance and loading return data in order of their arrival; storing the minimum necessary data for each context in its associated data store; storing a copy of data for peripheral actions in a queue to be processed asynchronously such that peripheral actions are performed separate to initiating and higher priority actions.

[023] In another aspect of embodiments described herein there is provided a method of displaying a unified contextual navigation in a clinical workflow management system comprising the steps of: selectively presenting a plurality of display panels comprising items grouped by context.

[024] In the above method of displaying a unified contextual navigation in a clinical workflow management system the display panels are preferably selectively displayed in the form of a flex accordion where opening a panel displaces adjacent panels.

[025] In yet another aspect of embodiments described herein there is provided a method of checking patient information against an external provider in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: raising a request from a client application API upon opening a patient record through a client application user interface for checking patient information against an external provider database; placing the request in a queue for further processing by a client application service acting as an interface between a client application API and a service provided by the external provider; the client application service checking for a cached request that corresponds to the raised request; returning a copy of a response matching the cached request from the client application service and stopping further processing of the raised request; the client application service continuing processing of the raised request if there is no cached request by forwarding the request to the external provider; the client application service forwarding any received response from the external provider to the client application to process including updating the patient details and/or notifying a user of the clinical workflow management system of the patient information.

[026] In still another aspect of embodiments described herein there is provided a method of searching a patient's medical history in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: creating at least one artefact comprising clinical or other data created in the course of providing medical services to a patient; storing the at least one artefact in at least one of the plurality of data stores; indexing the at least one artefact by parsing its content, splitting content into tokens, processing tokens, and creating an index of each of the tokenised data; entering a search query comprising search terms; tokenising each entered search query term; and, scoring stored indexes against the tokenised search query terms.

[027] In still yet another aspect of embodiments described herein there is provided a method managing data in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: recording an action taking place during a medical consultation as tokenised data; creating at least one artefact corresponding to the recorded action and to be used as a proxy for the recorded action.

[028] Yet a further aspect of embodiments described herein provides a method of managing data in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: creating at least one artefact comprising clinical or other data created in the course of providing medical services to a patient; storing the at least one artefact in at least one of the plurality of data stores; indexing the at least one artefact by parsing its content, splitting content into tokens, processing tokens, and creating an index of each of the tokenised data.

[029] Still another aspect of embodiments of the invention described herein provides a method of synchronising communication between clients in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: assigning categories to selected database tables in the plurality of data stores, the categories comprising one or a combination of user, center or patient; sending a message to at least one application client in the event one of the tables is modified, the message comprising the type of message and an identification; making an API call for retrieving all information if a relevant identification is received by an application client and in response; the application client updates a user interface to match information on a server of the clinical workflow management system.

[030] Preferred embodiments of the present invention provide for apparatus adapted to operate a clinical workflow management system, said apparatus including: processor means adapted to operate in accordance with a predetermined instruction set, said apparatus, in conjunction with said instruction set, being adapted to perform the method steps as described above and hereinbelow.

[031 ] Still further preferred embodiments of the present invention provide for a computer program product including: a computer usable medium having computer readable program code and computer readable system code embodied on said medium for operating a clinical workflow management system within a data processing system, said computer program product including: computer readable code within said computer usable medium for performing the method steps as described above and hereinbelow.

[032] Embodiments of the present invention provide a user interface comprising an algorithm adapted to keep the most relevant information display visible for the user. Preferably, the information display is configured as an accordion panel containing relevant information for the user. [033] Further, embodiments of the present invention provide a user interface, a Web server API and data storage adapted for use with a method for dynamically checking a patient's Medicare status comprising the use of a polling algorithm. with a timeline artefact having filtering functionality which is context aware with actions in a patient's health summary.

[034] Still further embodiments of the present invention provide a user interface, a Web server API and data storage adapted to act in conjunction to provide a health summary comprising an algorithm to show the most relevant medications.

[035] Further embodiments of the present invention provide a user interface comprising a unified contextual navigation workflow that keeps all key information visible and elements editable while completing actions, such as for example, prescribing, executing diagnostic requests, letter writer, and executing nursing requests, etc.

[036] Further embodiments of the present invention provide a user interface for a Web based interaction for a medical consultant to use an examinations module, select boxes, draw diagrams where these uses appear back in the consultant's notes and are editable.

[037] Further embodiments of the present invention provide a user interface, a Web server API and data storage adapted for updating a patient record by the current user or any other user and will be dynamically updated to all users viewing the record and available for use in future action activities.

[038] Further embodiments of the present invention provide a user interface, a Web server API and data storage adapted for interaction with a medical consultant wherein actions are tokenised and associated with the consultant and are adapted for re-opening, editing and reprinting.

[039] Further embodiments of the present invention provide a user interface for medical and/or clinical services adapted to expand demographic records with one input device action (such as a one-click) for editing.

[040] Further embodiments of the present invention provide a user interface, a Web server API and data storage adapted for use with a method for automatically checking drug interactions on relevant patient record alterations when part way through a prescription or immunisation.

[041 ] Further embodiments of the present invention provide a user interface providing a user the ability to tab only through a relevant module by a zoned focus in non-modal application so tab order moves through only the relevant sections and not through the whole application.

[042] Further embodiments of the present invention provide a user interface, a Web server API and data storage adapted for use with algorithms to assist application performance fast reads and slow writes.

[043] Further embodiments of the present invention provide a user interface adapted to facilitate multiple combinations of regions on the same page.

[044] Further embodiments of the present invention provide a user interface, a Web server API, data storage and a print agent adapted to allow local device interaction with a web based clinical record to capture information or print.

[045] Further embodiments of the present invention provide a clinical management data storage adapted for massive scalability by combining all billing and clinical workflows into a single application, and using bounded contexts from a domain driven design approach within the data models and an API where the aggregate data models, the boundaries between sub-domains and the messaging flows between them allows for separate deployments of individual components of the application across multiple resources.

[046] Other aspects and preferred forms are disclosed in the specification and/or defined in the appended claims, forming a part of the description of the invention.

[047] In essence, embodiments of the present invention stem from the realization that the combination of new user interface, navigation, data storage, contextual awareness and associated elements can radically simplify a clinician's most common tasks and provide dramatically improved patient care in an improved clinical workflow management system. [048] Some of the advantages provided by the present invention comprise the following:

• The unified navigation scheme of preferred embodiments enables a clinician to keep the full context of the patient's timeline, health summary and consultation notes in view, then quickly move to create new artefacts such as a prescription or referral while keeping the more relevant health summary and consultation notes visible and editable;

• Reduced clinical risk as contextual information is easily accessible during a consultation when compared to other clinical management systems;

• Workflow efficiencies due to the improved accessibility and navigation pathways to clinically relevant information;

• Automated suggestions for drugs or treatment based on available data;

• Automated suggestion for billing based on consultation time, and clinical information;

• Access to windows as required and not in a sequential way;

• Does not limit the user to completing a predetermined data entry task;

• The display of a timeline that moves from top to bottom with the ability to contain a broader range of content;

• Displays contextual information that relates to the activity being performed;

• Does not require system users to define rules.

[049] Further scope of applicability of embodiments of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the disclosure herein will become apparent to those skilled in the art from this detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

[050] Further disclosure, objects, advantages and aspects of preferred and other embodiments of the present invention may be better understood by those skilled in the relevant art by reference to the following description of embodiments taken in conjunction with the accompanying drawings, which are given by way of illustration only, and thus are not limitative of the disclosure herein, and in which: Figure 1 illustrates a Web based single page application user interface in accordance with a preferred embodiment of the invention;

Figure 2 depicts a vertical and horizontal navigation view of a single unified navigation scheme for clinical services management in accordance with an embodiment of the invention;

Figure 2a is a flow chart of a drug safety screening algorithm in accordance with an embodiment of the invention;

Figure 3 depicts a quick access navigation in a hyperlink vs horizontal/vertical navigation in accordance with an embodiment of the invention;

Figure 4 presents a clinical workflow displaying Queue, Timeline and Health Summary in accordance with an embodiment of the invention;

Figure 4a is a system block illustration featuring messaging diagrams in the components of the clinical management system of a preferred embodiment of the invention;

Figure 5 presents another clinical workflow displaying Timeline Health Summary and Consult in accordance with an embodiment of the invention;

Figure 6 presents another clinical workflow displaying Health Summary, Consult and Actions in accordance with an embodiment of the invention;

Figure 7 is a system block diagram of an exemplary implementation in accordance with embodiments of the invention;

Figures 8a to 8d is a series of diagrams representing the horizontal panel stack of an accordion navigation panel display in accordance with a preferred embodiment of the invention;

Figure 9 is a diagrammatic representation of an activity check in accordance with an embodiment of the invention;

Figure 10 is a message transfer diagram for a status request check in accordance with an embodiment of the invention;

Figure 1 1 is an application level system diagram of an embodiment of the invention;

Figure 12 is a client system level diagram of an embodiment of the invention;

Figure 13 is a diagrammatic representation of accessing multiple separate contexts in accordance with an embodiment of the invention;

Figure 14 is a bounded context map in accordance with embodiments of the present invention; Figure 15 is a message transfer diagram illustrating a basic sequence of request causing events in accordance with embodiments of the invention;

Figure 16 is a flow chart illustrating loading data from different context returned at different times in accordance with an embodiment of the invention;

Figure 17 is a screen view of a patient's health summary which is half loaded but ready to use in accordance with an embodiment of the invention;

Figure 18 is a screen view of health summary items shown in order of importance in accordance with an embodiment of the invention;

Figure 19 is another message transfer diagram illustrating sending requests in order of importance and loading as the request comes back in accordance with an embodiment of the invention;

Figure 20 is an event diagram illustrating a receptionist assigning a document causes update events for a doctor in accordance with an embodiment of the invention;

Figure 21 is another event diagram illustrating a doctor starting a consultation triggering updates to the receptionist view of the patient queue in accordance with an embodiment of the invention;

Figure 22 shows a system event in which a request failed to load family conditions with Patient details ready for use in accordance with an embodiment of the invention;

Figure 23 illustrates a system state diagram showing the process of creation of artefacts in an application database and indexed store in accordance with an embodiment of the invention;

Figure 24 illustrates a system state diagram showing a flow of indexing operations in accordance with an embodiment of the invention;

Figure 25 the process for searching of an artefact in accordance with an embodiment of the invention;

Figure 26 is an action artefact data flow diagram in accordance with an embodiment of the invention;

Figure 27 is a representation of an outstretched conceptual flex accordion navigation and display with all the available panels in accordance with an embodiment of the invention;

Figure 28 is a patient search view, which displays the patient search, patient timeline and health summary panels in accordance with an embodiment of the invention; Figure 29 is a health summary view, which displays the expandable views on both the left and right side of the accordion in accordance with an embodiment of the invention;

Figure 30 is a consultation view, which displays the health summary, consult summary and consult item panels containing a new prescription artefact in accordance with an embodiment of the invention;

Figure 31 is a consultation item view, which displays the consult summary, consult item and consult item child panels in accordance with an embodiment of the invention;

Figure 32 is a diagram showing a message notification illustrating synchronous communication between clients in accordance with an embodiment of the invention;

Figure 33 is a screenshot showing two forms open in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

[051 ] Embodiments as detailed hereinbelow, provide a number of efficiency and productivity improvements for a clinical workflow management system. In particular, the embodiments described herein provide solutions to complex clinical workflows by applying contextual relevance to the windows or panels that are displayed to a user in a clinical practice along with the information within those panels. A number of embodiments do not require system users to define rules and have predefined capability to display Health Summary with key information visible and display contextually relevant information based on the action being performed. Furthermore, where information needs to be filtered there is the capability to quickly filter based on date and event or information type from within the interface. In certain embodiments three panels of information are provided and are tied together working algorithmically ie; type filters based on smoking, nutrition, alcohol and physical activity (SNAP) interaction in the health summary.

[052] With initial reference to Figures 1 to 7, in a preferred embodiment of the present invention a cloud based clinical and practice management application is provided that employs a combination of web based components in conjunction with a unique user interface, navigation and contextual algorithms to enable clinicians to complete a broad range of workflows efficiently while reducing clinical risk. [053] Three facets of the practice management system in a preferred cloud-based application may be manifested by the following:

1 . User Interface - Web based single page application user interface. The user interface includes algorithms and navigation workflows that enable the clinician to complete the workflows.

2. Web Server API / Middleware - A REST Web API provides an interface between the web browser hosted front end and the data store. The Middleware messaging, algorithms and event systems enable the application's workflows.

3. Data Storage - A geo-redundant scalable data storage is provided preferably comprising Azure™ hosted components combined with a custom bounded context domain model along with custom encryption, permissions models and custom application code.

[054] The data storage architecture may comprise one or many databases for storage of practice, patient and billing data. A separate database is provided for each client and can store data for several medical practices that are operated by the client. Each database can be split along domain context boundaries to provide scalability through the use of multiple data stores. Each database is geo-replicated to another data centre to provide disaster recovery and prevent data loss. Implementation of actual data storage may be carried out using a broad range of Microsoft Azure™ Cloud services including: SQL Azure™, Azure DocumentDB™, Blob Storage™. In addition to custom encryption, permissions models and custom application code nHibernate is used as an object relational mapping layer to translate between database schema and business data objects.

[055] A Web server is utilised in the form of a REST Web API to provide an interface between a browser hosted front end and the data store. This may be implemented using Microsoft WebAPI and custom C#.net application code. A logging facility is provided using Seq and Azure Application Insights™. In this example, a messaging service hosted on the Web server provides access to the Australian Government Medicare services and data. Asynchronous transaction processing is achieved through the use of nService Bus. signaIR is used to provide synchronous communication between clients including the generation of events to keep multiple web clients up to date. [056] A client side application is provided as a rich client application hosted within a Web browser on a client computer. This application uses a single page application programming approach to create a responsive application for the user. It makes use of asynchronous API calls and Web sockets to provide data to the front-end user interface. The client side application is implemented using a broad combination of standard components such as AngularJS, Typescript, Node, Grunt, Gulp, SASS. As will become evident in the description of embodiments herein, the required outcome could not be achieved with off the shelf components and required extensive customisation to enable the unique contextual navigation, to keep the most relevant panel in view and to provide dynamic updates from multiple concurrent users. In preferred embodiments, a client side agent application provides access to physical devices such as printers, scanners and heart rate monitors attached to the client computer. In one form this may be implemented using custom C#.net code.

[057] A relevant domain being addressed by embodiments of the present invention is the efficiency and productivity of the medical services business, ie the eHealth domain. To accommodate the expected scale of the application a new approach to decomposing the eHealth business domain into separate components has been developed. Previous eHealth applications such as Medical Director™ and PracSoft™ have used separate billing and clinical applications to differentiate the workflow between these two functions, but still aggregate the data in a single data store. An embodiment of the present invention combines all billing and clinical workflows into a single application, but uses the concept of bounded contexts from a domain driven design approach within the data models and API. This unique approach of describing the aggregate data models, the boundaries between sub-domains and, the messaging flows between them allows for separate deployments of individual components of the application across multiple resources, thus providing massive scalability. The preferred application of embodiments aggregates the separate bounded contexts to work as a cohesive whole.

[058] Components of the clinical practice workflow management system of preferred embodiments are considered to provide the following contributions.

[059] With respect to the first facet, namely, the User Interface (Ul), in general, this provides the implementation of the unique navigation that a user of embodiments will interact with. The User Interface can be further decomposed into the following parts: • Ul-View:- This is the visual design for the Ul. This part represents the graphical elements and Ul controls that are presented to a user of embodiments of the invention;

• UI-ViewModel:- This model provides the algorithms to control the elements on the View, for example, what elements are displayed. It accesses data on behalf of the view and acts as a two-way conduit to provide data updates when elements on a view are changed and vice-versa; and,

• Ul-Model:- This model provides a client-side, in-memory, representation of the data associated with business domain objects.

[060] With respect to the second aspect, namely, the Web Server API, its component parts may be referenced as follows:

• Web Server API - Controller Layer:- This protocol layer coordinates the communication between client side Ul code and separate domain contexts. It provides data compression, object flattening and resource minification , ie removing all unnecessary characters from source code without changing its functionality;

• Web Server API - Contracts:- This controls the interfaces and events for each domain context to enable reliable inter context communication;

• Web Server API - Service Layer:- This protocol layer provides an interface between the domain context interface and the data repository. It encapsulates business logic and controls transactions;

• Web Server API - Repository Layer:- This protocol layer provides an embodiment of the domain contexts in software data object form. It describes the classes and their properties, methods, and the functionality to create and destroy these objects;

• Web Server API - ORM Layer:- This layer provides a mapping between the domain context objects and the underlying database schema. It contains the algorithms to load data into the domain objects from the data store, update the data store when objects are changed, create new database records when a new object is created and, delete database records when an object is deleted.

[061 ] Further protocol and application aspects of components of the clinical practice workflow management system of preferred embodiments, itemized below, are considered to provide the following contributions. • Data Layer:- This protocol layer provides a scalable data store for electronic health record data and documents used by embodiments of the invention. Clinical database schema is arranged to match the domain context boundaries in such a way that each context can reside in a separate database.

• Client Side Agent- This facility provides the ability for a web application to interact with local devices such as scanners, printers and medical devices and optimises configuration and print performance;

• Navigation (Steps):- These features provide the unique workflow capabilities of embodiments of the invention that enable users to efficiently complete a broad range of clinical task with contextual information visible and accessible.

[062] Interaction between the above noted components comes in several guises. In particular, the following interactions are noted. The interaction between the Ul and the Web Server API components provides the implementation of the unique navigation that a user of embodiments of the invention will interact with. The interaction between the Web Server API on the one hand, and each of the Ul, the Data Storage, and the Client Side Agent components, respectively, will provide the domain logic, messaging, interactive events, algorithms, and permissions to access the services that make up embodiments of the invention. The interaction between the Data Storage and the Web Server API components provides a scalable bounded context data store for electronic health record data used by embodiments of the invention. The interaction between the Client Side Agent and Web Server API components provides the ability for a web application to interact with local devices such as scanners, printers and medical devices and optimises configuration and print performance. The interaction between the features of the Navigation (Steps) and the Ul components provides the unique workflow capabilities of embodiments of the invention that enable users to efficiently complete a broad range of clinical tasks with contextual information visible and accessible.

[063] Further detailed description of preferred aspects and embodiments of the present invention follow.

Navigation System

[064] A preferred embodiment for a navigation system uses a Flexbox based navigation as a Flex Accordion Navigation System (FANS). Flexbox, the CSS3 Flexible Box, or flexbox, is a layout mode¹ providing for the arrangement of elements on a page such that the elements behave predictably when the page layout must accommodate different screen sizes and different display devices². In this preferred embodiment, the Flex based navigation system wraps the entire application and displays sections of the application in a horizontally stacked panel layout. Panels can be collapsed or expanded into various sizes by an operator via click/touch or programmatically, animating in and out, like the bellows of an accordion. Several configuration values exist which are used to control the behaviour of the panels at run time.

[065] Depending on the minimum/maximum flex configuration values, when a panel is expanded it will cause one or more other panels to collapse in the opposite direction. A panel can support different expanded sizes depending on the set max flex configuration value.

The Min/Max Flex Algorithm (MMFA)

[066] Each panel in the horizontal stack has several values associated to it. The algorithm takes 4 inputs to calculate what the FANS panel state should be. There are two constant values, namely Max Flex Value and Min Flex Value. These generally don't change. MMFA offers the ability for the programmer to set the value of just one of the panels and the other remaining panels will resize and adjust their position automatically.

Constant values

1 . Max Flex Value: The maximum Flex value allowed. This is the maximum number of expanded panels which are permitted to be visible at any one time. The sum of expanded panels flex value will not exceed this value.

[067] Each panel shares this value.

2. Min Flex Value: The minimum Flex value allowed. At a minimum, the sum of expanded panels flex value will need to equal this value. This is the minimum number of panels which must be shown at any one time. The number of

¹ https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_mode

" Using CSS Flexible Boxes, Mozilla Developer Network, Accessed 23 March 2017,

<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Using_CSS_flexible_boxes> panels visible can't be less than this number. This number must be less than or equal to the Max Flex Value.

[068] Each panel shares this value.

Dynamic Values

3. Expanded Panel Position: The panel's position in the horizontal panel stack. Unique for each panel. The panel numbering starts at one. This is analogous the ID of the panel on which the operation is being performed.

4. Expanded Panel size: The flex value of the expanded panel. These values are dependent on Max Flex Value.

0: The panel is collapsed n (where n > 0 and <= Max Flex Value): the width of the panel is defined as (n/Max Flex Value) * the width of the browser window (measured in pixels), less the width of any collapsed panels.

Examples:

[069] If the max flex configuration value was set to 3, then panels will support the following 3 Expanded Panel Sizes:

0 = Collapse panel

1 = ½ of the available space

2 = ¾ of the available space

3 = Fill the available space

Note: only one panel value can be set at any one time. Other panels will have their size and position adjusted automatically because of the values set by this operation.

[070] If the Max Flex Value was set to 5, then panels will support the following 5 Expanded Panel Sizes.

0 = Collapse panel

1 = ½ of the available space

2 = ¾ of the available space

3 = ³/s of the available space

4 = % of the available space 5 = Fill the available space

Note If the Max Flex Value is set to 1 , then panels will only support one Expanded Panel Size "Fill the available space", which would usually be used for smaller resolutions found on mobile/tablet devices.

[071 ] When a panel is expanded, FANS (via the M in/Max Flex Algorithm) looks at the position of the panel in comparison to the panel stack, the size it has been expanded to and based on the min/max flex configuration values calculates which panels should be expanded or collapsed to fulfil the min/max flex rule and expanded stack order.

[072] When a panel is collapsed or expanded, FANS will fire a before/after event containing information about each panel's current state (expanded size or collapsed), so that any child components can listen to the event and act accordingly.

How it works

[073] Figures 1 a to 1X are a series of diagrams representing the horizontal panel stack. The stack consists of 5 panels. The number within each panel represents the panel size or flex value. For the following series of examples the min/max flex values are set to the following:

Max Flex Value= 3

Min Flex Value = 3

[074] In Figure 1 a, Panel 1 has been expanded to Expanded Panel Size = 1 , however because the Expanded Panel Size value of 1 does not meet the Min Flex Value of 3, Panel 2 and 3 are expanded to meet the max flex value of 3. If Panel 4 were to be expanded, the combined total of Expanded Panel Sizes for all visible panels would be greater than Max Flex Value, hence Panel 4 is collapsed. The Min/Max Flex Algorithm checks to see at which end the panels are expanding. In this example, Panel 1 is expanding, so panels to the right will also be expanded or collapsed according to the limits set by Min Flex Value and Max Flex Value.

[075] In Figure 1 b, Panel 4 has been expanded to Expanded Panel Size = 1 , however because the Expanded Panel Size value of 1 does not meet the Min Flex Value of 3, Panel 3 and 2 are expanded to meet the max flex value of 3. If Panel 1 were to be expanded, the combined total of Expanded Panel Sizes for all visible panels would be greater than Max Flex Value, hence Panel 1 is collapsed. The Min/Max Flex Algorithm checks to see at which end the panels are expanding. In this example, Panel 4 is expanding, so panels to the left will also expanded or collapsed according to the limits set by Min Flex Value and Max Flex Value.

[076] In Figure 1 c, Panel 4 has been expanded to Expanded Panel Size = 2 (i.e. % the size of the width of the window), however because the Expanded Panel Size value of 2 does not meet the Min Flex Value of 3, Panel 3 is expanded to meet the max flex value of 3. If Panel 1 or 2 were to be expanded, the combined total of Expanded Panel Sizes for all visible panels would be greater than Max Flex Value, hence Panel 1 and Panel 2 are both collapsed. The Min/Max Flex Algorithm checks to see at which end the panels are expanding. In this example, Panel 4 is expanding, so panels to the left will also expanded or collapsed according to the limits set by Min Flex Value and Max Flex Value.

[077] In Figure 1 d, Panel 4 has been expanded to Expanded Panel Size = 3 (i.e. the full width of the window). Because the Expanded Panel Size value of 3 equals the Min Flex Value of 3, any other panels are collapsed. If Panels 1 , 2 or 3 were to be expanded, the combined total of Expanded Panel Sizes for all visible panels would be greater than Max Flex Value, hence Panel 1 , Panel 2 and Panel 3 are all collapsed. The Min/Max Flex Algorithm checks to see at which end the panels are expanding. In this example, Panel 4 is expanding, so panels to the left will also expanded or collapsed according to the limits set by Min Flex Value and Max Flex Value.

[078] In another embodiment, there is provided a Unified Contextual Navigation workflow that keeps all key information visible and elements editable while completing actions. With this embodiment, a Unified Contextual Navigation workflow that keeps all key information visible and elements editable while completing actions. Such actions may comprise prescribing, diagnostic requests, letter writer, nursing request, etc.

[079] In this embodiment, a 3 panel flex accordion style navigation has been chosen which shows and hides 3 panels at any one time depending on the user's selection. Each panel displays items grouped by context to help maximize relevant information on the available platform. Currently this is made for computers only but this underlying style was put in place to be extended to mobile platforms and other devices in the future. [080] Figure 27 shows the stretched out flex accordion with each panel's context.

[081 ] Figure 28 is a 3 panel example of a patient search which displays the patient search, patient timeline and the health summary panels.

[082] Figure 29 shows the health summary view which has minimized views on the left and right showing how the accordion can be expanded on either side.

[083] Grouping the context allows a smooth flow for the user navigating left to right. An example in figure 30 shows all the consultation items grouped in the consultation summary which opens the consultation item panel to its right. Figure 30 shows the consultation item child panel opened.

[084] In this embodiment, the following terms have the meanings as given :

• Unified Contextual Navigation workflow -this is the grouping of items in the same context and basing the navigation on the contexts rather than pages which usually hold many contexts.

• Flex accordion style navigation - Navigating pages by opening and closing pages on either side of the middle, much like an accordion opens and closes.

[085] In another embodiment, synchronous communication between clients is provided.

1 ) When a user, center or patient is opened, the system subscribes to relevant events and updates the client to keep it synchronized with the server.

2) When a user opens a client a connection is made to the server. This stays open for the lifetime of the client. If the network is disrupted the client will try to reestablish a connection until the client closes or it connects.

[086] When a user logs in they will subscribe to any events related to the current user. When a user selects a patient they will subscribe to any events related to the selected patient. When a user selects a center they will subscribe to any events related to the selected center.

[087] Notifying is shown with reference to Figure 32. In this embodiment, a server operates, and is labelled as the helix server, where appropriate events are raised which send a message to the helix client. Select database tables are assigned categories (user, center or patient) and if one of these tables are added to/updated a message is sent to the helix client. These messages are very small, only containing the type of message and an id. Each component in the helix client subscribes to events that it is interested in. If the id is relevant an api call is made to get all of the information. The helix client then updates the user interface to match what is on the server.

[088] In this embodiment, the following terms have the meanings as given :

• User: a user in helix

• Center: a center in helix

• Patient: a patient in helix

• helix client: a tab in a browser that has helix loaded

• helix server: an instance of helix running in a web server

• subscribe: in the helix server, a matrix of all users and the events they care about are stored.

• id: a unique identifier between 1 and 2147483647

• api: application program interface

[089] Advantageously, when a patient record is opened it is out of date when anything changes. By updating the patient record when it is changed by an external source or another helix user, the doctor will see the most up to date patient record.

Drug Interactions Check

[090] The existing drug interactions check is performed against current prescriptions, medications, allergies. This embodiment provides dynamic immunisations drug interactions with algorithms to automatically check interactions on relevant patient record changes even when part way through prescription or immunisations.

[091 ] However, in accordance with this embodiment, when a single immunisation is being recorded or a nursing request (for one or more immunisations) is being created, a drug interactions check is performed. This check is a more advanced version of the existing drug interactions check. The advancement is in terms of the way, the partial prescriptions, one or more immunisations selected for Nursing Request/Record are considered when doing the drug interactions check. When a single immunisation is being recorded, then drug IDs are considered for interactions check and includes the partially created prescriptions, nursing requests and unsaved medications. Similarly, when one or more immunisations are selected for a nursing request, then the drug interaction also checks the immunisations for drug interactions amongst themselves. This embodiment improves on other systems where a drug interactions check is only performed against the previous state of the patient record. The check algorithm also checks all ordered immunisations against themselves as well as checking partially finished prescriptions and partially updated medications.

[092] In this embodiment, the following terms have the meanings as given:

• Immunization: A drug that is used to immunise against a disease. In this instance, it is treated like any other drug that can have an interaction;

• nursing request: An order sent to a nurse to administer an immunization. For the purposes of this embodiment, this is the same as administering an immunization yourself;

• drug interactions check: an engine that runs on the server that can tell if two or more drugs interact with each other.

[093] With reference to Figure 9, all pertinent information is sent to the drug interactions engine to check for interactions. In this embodiment a medication can be changed/updated or added to. A prescription can also be created without being saved on the server and finalized. Unlike other clinical systems, the process of the present embodiment will do a drug interactions check against these staged items. The system will also do a drug interactions check against other immunisations that are ordered at the same time. This will prevent doctors from ordering immunisations that will interact with medications that they are thinking about prescribing. Since the dynamic interactions is considering the partial prescriptions/immunisations, the possibility of creating a pending immunization for the same type of vaccine would be prevented. The user gets a chance to review the partial prescription and immunisations selected and discard/remove the ones that are conflicting. Figure 2a shows a flow chart of a suitable algorithm to meet these functions.

[094] In another embodiment, the present invention provides for a Medicare polling algorithm to dynamically check the patients details and Medicare status.

[095] In the prior art, clinical management system of PracSoft™ the eligibility status check is primarily triggered manually by a user. An option to automatically perform an eligibility status check is available (if configured) but only performed prior to billing and not when opening a patient record. However, with this solution the client application blocks while waiting for response for the external status check from the external provider's system.

[096] This embodiment automates the process of checking patient demographics captured in a client application against an external provider to verify the patient's details and eligibility status. The processing of the request is performed asynchronously in a non-blocking way so that the client application can continue other tasks while waiting for a response. In order to speed up the process and reduce unnecessary communication with the external provider, previous responses for the same or similar requests within a given timeframe are cached and re-used.

[097] With reference to Figure 10, on opening a patient record through the client application Ul, a request will automatically be raised in the background to check the patient demographics and eligibility status against the details from an external provider. The request is placed on a queue for further processing by the client application service. The client application service acts as an interface between the client application API and the service provided by an external provider.

[098] With reference to Figures 4a, 1 1 , and 12 during the initial stage of processing the client application service will first check to see if the same or similar request has already been processed since a given point in time (e.g. within the past N hours or days). If a matching request has already been processed the client application service will return a copy of this response from a cache and stop processing the request. If a matching request has not been processed or was last processed prior to the timeframe given the client application service will continue processing the request by forwarding it to the external provider via the client adaptor and wait for a response. The response from the external provider is then returned back to the calling client application to handle.

[099] On receiving the response back from the client application service, the client application will process the response and update the patient details if required (e.g. update patient name) and notify the user of the system of the outcome of the eligibility status check. In respect of this embodiment, the following terms have the meanings listed below: • Client Adaptor: The Medicare Client Adapter is an interface provided by Medicare that provide access to the Medicare claiming and patient verification interfaces.

• Client Application API: A component of the client application system that contains the majority of the business logic.

• Client Application Service: A component of the client application system that runs as a separate process and is responsible for processing internal requests asynchronously and communicating with the external provider via the client adaptor.

• Client Application System: The application that is capturing the patient details and checking for matches against the external provider's system.

• Client Application Ul: A component of the Client Application System that provides the user interface.

• Eligibility Status: In the context of a Medicare patient the eligibility status indicates if this Patient is entitled to make claims with Medicare for services provided.

• External Provider: A third party that is providing a service to check patient details (e.g. Medicare Australia)

• Patient Demographics: Details that uniquely identify the patient (e.g. name, date of birth, card numbers)

• Request: A data packet that contains the patient details to check with the external provider

• Response: A data packet containing the result of the check against the external provider's data. The response may include the details of a match if it exists in the external provider's system or an error response if no match is found or an error occurred.

[100] The advantage of this embodiment is that the process of checking the patient details between the source system and the external provider's system is automated. Other than triggering the process by opening a record in the client no other manual interaction is required to transmit the request to the external provider. A user of the system can continue with other tasks as the process is completed in the background and notified once a result is returned [101 ] Another advantage of this embodiment is that unnecessary communication between the system and an external provider is reduced by returning cached responses for matching requests within a given timeframe. This reduces network traffic and increases overall speed.

[102] In another embodiment, a reduction in wait time and down time is provided for important functions to allow more consultation time for doctors.

[103] Eventual consistency3 describes the use of scaling multiple databases where data will propagate across servers in their original shape, but doesn't describe data in a different shape being cloned or a cached view of data. Event driven architecture4 describes the use of events for doing peripheral work. Domain driven designs describes designing code through separate contexts or viewpoints but not necessarily splitting each context physically.

[104] This embodiment provides the doctors with more time consulting patients and less time spent using the clinical management system by increasing availability of the systems functions and reducing system wait time through the combination of technologies and methodologies such as Domain Driven Design, Bounded Context, Web API, NServiceBus and client side programming.

[105] Select actions are not performed immediately so that areas of the application which must be performed can continue without the need to wait for that action. A doctor can select a patient and open a new consultation with important items loading as early as possible allowing them to start the consultation without being blocked by items of lesser importance or waiting for all items to load. A doctor can continue to consult patients even though a different area of the application is not running (for example appointments, reports or billing is down).

[106] With reference to Figure 13 each context has its own set of API methods and database. In accordance with the embodiment the API methods are called and combine related information on the client side as each call is returned rather than waiting for all calls to be returned then displaying. Figure 14 shows the full bounded context map.

³ https://en.wikipedia.org/wiki/Eventual_consistency

⁴ https://en.wikipedia.org/wiki/Event-dnven_architecture

⁵ https://en, wikipedia.org/wiki/Domain-driven_design [107] With reference to Figure 15, system wait time is reduced. When a save is initiated there may be peripheral actions that need to occur which are not immediately needed, a message is stored on a queue that will be processed asynchronously so that those actions can be performed separately to the initiating action. The peripheral actions store a copy of the original data, potentially in an alternative view state (e.g. multiple classes combined/flattened/aggregated) so that the data can be retrieved for its own needs in a form that doesn't need alteration. This is essentially a long-term cache stored in the data store.

[108] Each bounded context stores minimal and necessary data resulting in quicker and more efficient queries to the database. A patient in the common context has more than 20 properties/fields. A scheduling patient has 5 (only what's required for an appointment) which results in quicker searches for scheduling patients as less data is returned. If both a common patient search and scheduling patient search is requested at the same time, both will return quicker than if they were both stored in the same table (two tables queried once each simultaneously rather than one table queried twice).

[109] System wait time may be reduced by allocating more resources to contexts of more importance. Billing and reports may not be as important timewise as a consult and could have less server resources allocated to them.

[1 10] With reference to Figure 16, items load client side as they are returned from the web API. On selecting a consult for a patient, many API calls are made to the different contexts and loaded as they are returned. Figure 17 shows a page that has items not yet loaded highlighted in red but is ready to have the patients smoking information recorded.

[1 1 1 ] Items on the consultation to be displayed in order of importance from top left to bottom right so the doctor has an easy path to follow. Figure 18 illustrates health summary items shown in order of importance.

[1 12] With respect to Figure 19, loading items for a consultation are requested in the order of importance to increase the chances of the important items being loaded first however the system will load the items in the order they are returned to load the whole consultation as soon as possible. [1 13] Availability of system functions is increased by data duplication and separation of contexts decreases the chances of functions blocking each other. For example, the database in the scheduling context runs out of memory and appointments can no longer be created, this will not stop a doctor for searching for patients and creating consultations as they are not in the same context.

[1 14] Data is kept in sync using NServiceBus™ through server side events in a publish/subscribe pattern. NServiceBus™ allows a context to continue working whilst another context is down with confidence the data will be updated when the context becomes available again. Figure 20 shows an example of a receptionist assigning a patient to a document while a doctor looks at the patient's documents. Figure 21 shows a doctor starting a consultation which triggers an update of the patient queue. Another example in Figure 22 shows family history failed to load but the user is still able to edit the patient's details.

[1 15] In respect of this embodiment, the following terms have the meanings listed below:

• System Functions - Any functionality the system provides to the user. For example, search for a patient, create a consultation, record smoking information, record alcohol information, create appointments etc

• System wait time - The time between a system function and the system returning to a useable state. For instance, the doctor selects to open a patient consultation and the system becomes available for the doctor to start the consultation, the system wait time is the delay between the 2 events.

• Domain Driven Design (DDD) - Designing the application around domain logic.

• Bounded Context - A core principal of DDD which is binding domains based on common entities, for example, the clinical and scheduling contexts both have patients.

• Web API - an Application Programming Interface used to provide backend services to the application such as business logic and storing data.

• NServiceBus - A dot net technology used to decouple applications by passing messages between multiple parties.

• Client Side Programming - The use of JavaScript programming on the client (the users machine rather than the server) in embodiments to provide quicker response as there is not as many back and forward calls to the server. • Items - Any piece of information in the system, for example, smoking status, smoking quit date, family conditions, medications, etc.

• API methods - methods provided by the Web API service such as create patient, update patient, create appointment, delete appointment, etc.

• Bounded context map - a diagram containing each bounded context for embodiments and how they relate to each other.

• Data duplication - Entities which belong to multiple contexts will be duplicated as each context needs their own copy to run independently, for example, patient exists in multiple contexts.

[1 16] In another embodiment, a timeline artefact that filters is provided and, which is context aware with actions in Health summary.

[1 17] This embodiment will allow authorised users of an application to perform free- text searching of historical clinical artefacts created as part of a consult, or otherwise included in the patient's timeline. These clinical artefacts will include, but are not limited to: prescriptions, pathology and imaging requests and results, specialist referrals and other letters, clinical measurements, and clinical notes.

[1 18] This will be implemented by storing and indexing metadata of the artefact to allow key words in the title or content of the artefact to be retrieved, displayed and ordered by relevance to the user who performed the search. In this way, the user will be able to perform targeted or exploratory searches into the patient's medical history to provide insights they may not have otherwise found.

[1 19] With reference to Figure 23, the process of creation of artefacts in the application database and indexed store is illustrated. Artefacts are created either by user actions or incoming streams of data. The artefact content is stored in the application database and may be immediately displayed to the creator. In a separate process, the artefact content and other metadata is indexed and stored, so that it can be efficiently queried.

[120] With reference to Figure 24 the process of indexing data from an artefact relies on:

• parsing the content as plain text;

• splitting the content into words or phrases known as tokens; • removing or changing these tokens, for example: removing words like "a" or "the", replacing pluralised words with their singular forms, or replacing words with a synonym;

• creating an index of the term and its location in the text.

[121 ] With reference to Figure 25, to allow searching the indexed data, a search query or search term can be entered. This query can be tokenised as outlined above and indexes in the store will be scored against the tokenised search terms

[122] In respect of this embodiment, the following terms have the meanings listed below:

• Artefacts - clinical or other data created in the course of providing medical care to a patient, including such things that have been created in the course of a consult, or provided to the application by any other means.

• Consultation - the interaction between a doctor and a patient for the purpose of providing care.

• Timeline - a historical record of all medical information relating to a patient that has been organised in such a way that it is displayed to the doctor in reverse chronological order and grouped by consult

[123] By allowing for advanced searching of a patient's medical history, advantageously this embodiment allows those providing medical care to the patient to find relevant medical history more quickly and efficiently, resulting in an increased standard of care.

[124] In another embodiment, actions are tokenized, associated with the consultation and can be re-opened edited, reprinted etc.

[125] The prior art system embodied in the product MedicalDirector Clinical™ uses a plain text entry in an editable area to represent a log of actions performed in a consultation. These entries are independent to the original action and can be modified by the user, which could lead to confusion.

[126] Actions which have taken place during a consultation are added as tokenized data so that only select functions can be performed on them. The structure of the tokens is the same as the final historical timeline to ensure that what is seen during a consultation is the same as after the consultation has been completed. An action is performed by some part of the application, such as taking a measurement, prescribing a drug, writing a letter, etc. When the action is performed (saved) an event is raised and an artefact is added to represent that action. The artefact is then used as a proxy for the action which can be used to initiate updates, reprints etc. When any update to the original action is performed the artefact will be updated to reflect the update.

[127] With reference to Figure 26, once a consultation has been started any number of actions may be performed. These actions are saved to the database and an event is raised when that has been done. The event is then handled by creating a new action artefact for the consultation which is saved as a snapshot of the action that was performed. The action artefact is then shown on the user interface as a proxy to perform any further changes. Once the consultation is completed the action artefact is shown in a historical timeline. This allows the action artefact to be decoupled from the original action for flexibility, multiple actions can result in only one artefact, or one action could result in many artefacts.

[128] In respect of this embodiment, the following terms have the meanings listed below:

• Action - Some action which can take place during a consultation, such as a measurement being taken, a drug being prescribed, etc.

• Artefact - A representation of some action, a snapshot of data.

• Consultation - A medical consultation between a patient and a doctor.

• Timeline - A historical account of patients' consultations.

[129] Advantageously, since this embodiment does not allow the user to manipulate the entry independently of the original action the resulting history is more accurate. The action artefact then also becomes a more useful proxy to alter the original action which is not possible with a plain text log of the action.

[130] In another embodiment, zoned focus in non-modal application is provided so tab order moves through only the relevant sections and not through the whole applications. This embodiment hijacks the browsers "keydown event" and keeps a 'forms' focus. In a browser when a user presses tab focus will move to the next control in page. As this embodiment is a single page application there are many forms on the page at one time. This may cause undesirable keyboard navigation. To solve this problem a keyboard tab manager directive is provided. This allows for defining areas of the screen. These areas are now self-contained and if tab is pressed on the last element, focus is given to the first control in the area. The shift modifier is also supported, so if a user presses shift+tab, the focus is given to the previous control. Also if the first control has focus when shift+tab is pressed, the last control will be given focus.

[131 ] With reference to Figure 26, in this screenshot there are two forms open, the BMI form on the left and the Measurements form on the right. Before this, the focus would jump between forms, disorientating users. Now, when a user is in the BMI form and the notes field has focus, pressing tab will move to the address bar and then the next tab will go to the height input field.

[132] In respect of this embodiment, the following terms have the meanings listed below:

• Browser: a web browser ie google chrome

• DOM: Document Object Model - a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document.

• Directive: helix is written using a framework from google called Angularjs.

Angularjs Directives are markers on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS's HTML compiler ($compile) to attach a specified behavior to that DOM element (e.g. via event listeners), or even to transform the DOM element and its children.

• Control: any element in the DOM that can be selected with the following selectors: a[href], area[href], input, select, textarea, button, iframe, object, embed, *[tabindex], *[contenteditable], dhx_cal_data

[133] Whilst embodiments of the present invention have been described in the context of use for managing clinical workflows for general practitioners and/or specialists within medical practices, further embodiments of the present invention are envisaged for use and application into other healthcare areas.

[134] While this invention has been described in connection with specific embodiments thereof, it will be understood that it is capable of further modification(s). This application is intended to cover any variations uses or adaptations of the invention following in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains and as may be applied to the essential features hereinbefore set forth.

[135] As the present invention may be embodied in several forms without departing from the spirit of the essential characteristics of the invention, it should be understood that the above described embodiments are not to limit the present invention unless otherwise specified, but rather should be construed broadly within the spirit and scope of the invention as defined in the appended claims. The described embodiments are to be considered in all respects as illustrative only and not restrictive.

[136] By way of example, whilst a preferred embodiment of the present invention is implemented as a cloud based web application served to desk top devices with a local agent installed, in other exemplary embodiments, the present invention may be implemented as a cloud based web application served to mobile smartphone devices. Furthermore, in other exemplary embodiments, the present invention may be implemented as a cloud based web application served to tablet devices. In still more exemplary embodiments, the present invention may be implemented as a cloud based web application served to virtual reality or augmented reality devices.

[137] Various modifications and equivalent arrangements are intended to be included within the spirit and scope of the invention and appended claims. Therefore, the specific embodiments are to be understood to be illustrative of the many ways in which the principles of the present invention may be practiced. In the following claims, any means-plus-function clauses are intended to cover structures as performing the defined function and not only structural equivalents, but also equivalent structures. For example, although a nail and a screw may not be structural equivalents in that a nail employs a cylindrical surface to secure wooden parts together, whereas a screw employs a helical surface to secure wooden parts together, in the environment of fastening wooden parts, a nail and a screw are equivalent structures.

[138] The following sections I - VII provide a guide to interpreting the present specification.

I. Terms [139] The term "product" means any machine, manufacture and/or composition of matter, unless expressly specified otherwise.

[140] The term "process" means any process, algorithm, method or the like, unless expressly specified otherwise.

[141] Each process (whether called a method, algorithm or otherwise) inherently includes one or more steps, and therefore all references to a "step" or "steps" of a process have an inherent antecedent basis in the mere recitation of the term 'process' or a like term. Accordingly, any reference in a claim to a 'step' or 'steps' of a process has sufficient antecedent basis.

[142] The term "invention" and the like mean "the one or more inventions disclosed in this specification", unless expressly specified otherwise.

[143] The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", "certain embodiments", "one embodiment", "another embodiment" and the like mean "one or more (but not all) embodiments of the disclosed invention(s)", unless expressly specified otherwise.

[144] The term "variation" of an invention means an embodiment of the invention, unless expressly specified otherwise.

[145] A reference to "another embodiment" in describing an embodiment does not imply that the referenced embodiment is mutually exclusive with another embodiment (e.g., an embodiment described before the referenced embodiment), unless expressly specified otherwise.

[146] The terms "including", "comprising" and variations thereof mean "including but not limited to", unless expressly specified otherwise.

[147] The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

[148] The term "plurality" means "two or more", unless expressly specified otherwise. [149] The term "herein" means "in the present specification, including anything which may be incorporated by reference", unless expressly specified otherwise.

[150] The phrase "at least one of, when such phrase modifies a plurality of things (such as an enumerated list of things), means any combination of one or more of those things, unless expressly specified otherwise. For example, the phrase "at least one of a widget, a car and a wheel" means either (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car, (v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, a car and a wheel. The phrase "at least one of, when such phrase modifies a plurality of things, does not mean "one of each of the plurality of things.

[151] Numerical terms such as "one", "two", etc. when used as cardinal numbers to indicate quantity of something (e.g., one widget, two widgets), mean the quantity indicated by that numerical term, but do not mean at least the quantity indicated by that numerical term. For example, the phrase "one widget" does not mean "at least one widget", and therefore the phrase "one widget" does not cover, e.g., two widgets.

[152] The phrase "based on" does not mean "based only on", unless expressly specified otherwise. In other words, the phrase "based on" describes both "based only on" and "based at least on". The phrase "based at least on" is equivalent to the phrase "based at least in part on".

[153] The term "represent" and like terms are not exclusive, unless expressly specified otherwise. For example, the term "represents" do not mean "represents only", unless expressly specified otherwise. In other words, the phrase "the data represents a credit card number" describes both "the data represents only a credit card number" and "the data represents a credit card number and the data also represents something else".

[154] The term "whereby" is used herein only to precede a clause or other set of words that express only the intended result, objective or consequence of something that is previously and explicitly recited. Thus, when the term "whereby" is used in a claim, the clause or other words that the term "whereby" modifies do not establish specific further limitations of the claim or otherwise restricts the meaning or scope of the claim.

[155] The term "e.g." and like terms mean "for example", and thus does not limit the term or phrase it explains. For example, in the sentence "the computer sends data (e.g., instructions, a data structure) over the Internet", the term "e.g." explains that "instructions" are an example of "data" that the computer may send over the Internet, and also explains that "a data structure" is an example of "data" that the computer may send over the Internet. However, both "instructions" and "a data structure" are merely examples of "data", and other things besides "instructions" and "a data structure" can be "data".

[156] The term "i.e." and like terms mean "that is", and thus limits the term or phrase it explains. For example, in the sentence "the computer sends data (i.e., instructions) over the Internet", the term "i.e." explains that "instructions" are the "data" that the computer sends over the Internet.

[157] Any given numerical range shall include whole and fractions of numbers within the range. For example, the range "1 to 10" shall be interpreted to specifically include whole numbers between 1 and 10 (e.g., 2, 3, 4, . . . 9) and non-whole numbers (e.g., 1.1 ,

I .2, . . . 1 .9).

[158] The term "geo-replicated" refers to a type of data storage replication in which the same data is stored on servers in multiple distant physical locations. Typically, data is created or updated in a primary location and then asynchronously replicated to a secondary location so that the same data exists (and is backed up) in both locations. Ideally, these locations remain completely independent of each other, with no need to communicate with one another beyond data transfer. By way of example, Windows Azure™ offers geo-replication as part of its data storage packages.

[159] The term "bounded context" is reference to a boundary, or a 'fence', that literally distinguishes between the context of one subdomain from the context of another subdomain in a project.

II. Determining

[160] The term "determining" and grammatical variants thereof (e.g., to determine a price, determining a value, determine an object which meets a certain criterion) is used in an extremely broad sense. The term "determining" encompasses a wide variety of actions and therefore "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, "determining" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, "determining" can include resolving, selecting, choosing, establishing, and the like.

[161 ] The term "determining" does not imply certainty or absolute precision, and therefore "determining" can include estimating, extrapolating, predicting, guessing and the like.

[162] The term "determining" does not imply that mathematical processing must be performed, and does not imply that numerical methods must be used, and does not imply that an algorithm or process is used.

[163] The term "determining" does not imply that any particular device must be used. For example, a computer need not necessarily perform the determining.

III. Indication

[164] The term "indication" is used in an extremely broad sense. The term "indication" may, among other things, encompass a sign, symptom, or token of something else.

[165] The term "indication" may be used to refer to any indicia and/or other information indicative of or associated with a subject, item, entity, and/or other object and/or idea.

[166] As used herein, the phrases "information indicative of and "indicia" may be used to refer to any information that represents, describes, and/or is otherwise associated with a related entity, subject, or object.

[167] Indicia of information may include, for example, a symbol, a code, a reference, a link, a signal, an identifier, and/or any combination thereof and/or any other informative representation associated with the information.

[168] In some embodiments, indicia of information (or indicative of the information) may be or include the information itself and/or any portion or component of the information. In some embodiments, an indication may include a request, a solicitation, a broadcast, and/or any other form of information gathering and/or dissemination.

IV. Forms of Sentences [169] Where a limitation of a first claim would cover one of a feature as well as more than one of a feature (e.g., a limitation such as "at least one widget" covers one widget as well as more than one widget), and where in a second claim that depends on the first claim, the second claim uses a definite article "the" to refer to the limitation (e.g., "the widget"), this does not imply that the first claim covers only one of the feature, and this does not imply that the second claim covers only one of the feature (e.g., "the widget" can cover both one widget and more than one widget).

[170] When an ordinal number (such as "first", "second", "third" and so on) is used as an adjective before a term, that ordinal number is used (unless expressly specified otherwise) merely to indicate a particular feature, such as to distinguish that particular feature from another feature that is described by the same term or by a similar term. For example, a "first widget" may be so named merely to distinguish it from, e.g., a "second widget". Thus, the mere usage of the ordinal numbers "first" and "second" before the term "widget" does not indicate any other relationship between the two widgets, and likewise does not indicate any other characteristics of either or both widgets. For example, the mere usage of the ordinal numbers "first" and "second" before the term "widget" (1 ) does not indicate that either widget comes before or after any other in order or location; (2) does not indicate that either widget occurs or acts before or after any other in time; and (3) does not indicate that either widget ranks above or below any other, as in importance or quality. In addition, the mere usage of ordinal numbers does not define a numerical limit to the features identified with the ordinal numbers. For example, the mere usage of the ordinal numbers "first" and "second" before the term "widget" does not indicate that there must be no more than two widgets.

[171 ] When a single device or article is described herein, more than one device/article (whether or not they cooperate) may alternatively be used in place of the single device/article that is described. Accordingly, the functionality that is described as being possessed by a device may alternatively be possessed by more than one device/article (whether or not they cooperate).

[172] Similarly, where more than one device or article is described herein (whether or not they cooperate), a single device/article may alternatively be used in place of the more than one device or article that is described. For example, a plurality of computer- based devices may be substituted with a single computer-based device. Accordingly, the various functionality that is described as being possessed by more than one device or article may alternatively be possessed by a single device/article.

[173] The functionality and/or the features of a single device that is described may be alternatively embodied by one or more other devices which are described but are not explicitly described as having such functionality/features. Thus, other embodiments need not include the described device itself, but rather can include the one or more other devices which would, in those other embodiments, have such functionality/features.

V. Disclosed Examples and Terminology Are Not Limiting

[174] Neither the Title nor the Abstract in this specification is intended to be taken as limiting in any way as the scope of the disclosed invention(s). The title and headings of sections provided in the specification are for convenience only, and are not to be taken as limiting the disclosure in any way.

[175] Numerous embodiments are described in the present application, and are presented for illustrative purposes only. The described embodiments are not, and are not intended to be, limiting in any sense. The presently disclosed invention(s) are widely applicable to numerous embodiments, as is readily apparent from the disclosure. One of ordinary skill in the art will recognise that the disclosed invention(s) may be practised with various modifications and alterations, such as structural, logical, software, and electrical modifications. Although particular features of the disclosed invention(s) may be described with reference to one or more particular embodiments and/or drawings, it should be understood that such features are not limited to usage in the one or more particular embodiments or drawings with reference to which they are described, unless expressly specified otherwise.

[176] The present disclosure is not a literal description of all embodiments of the invention(s). Also, the present disclosure is not a listing of features of the invention(s) which must be present in all embodiments.

[177] Devices that are described as in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. On the contrary, such devices need only transmit to each other as necessary or desirable, and may actually refrain from exchanging data most of the time. For example, a machine in communication with another machine via the Internet may not transmit data to the other machine for long period of time (e.g. weeks at a time). In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

[178] A description of an embodiment with several components or features does not imply that all or even any of such components/features are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention(s). Unless otherwise specified explicitly, no component/feature is essential or required.

[179] Although process steps, operations, algorithms or the like may be described in a particular sequential order, such processes may be configured to work in different orders. In other words, any sequence or order of steps that may be explicitly described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to the invention(s), and does not imply that the illustrated process is preferred.

[180] Although a process may be described as including a plurality of steps, that does not imply that all or any of the steps are preferred, essential or required. Various other embodiments within the scope of the described invention(s) include other processes that omit some or all of the described steps. Unless otherwise specified explicitly, no step is essential or required.

[181 ] Although a process may be described singly or without reference to other products or methods, in an embodiment the process may interact with other products or methods. For example, such interaction may include linking one business model to another business model. Such interaction may be provided to enhance the flexibility or desirability of the process.

[182] Although a product may be described as including a plurality of components, aspects, qualities, characteristics and/or features, that does not indicate that any or all of the plurality are preferred, essential or required. Various other embodiments within the scope of the described invention(s) include other products that omit some or all of the described plurality.

[183] An enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. Likewise, an enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are comprehensive of any category, unless expressly specified otherwise. For example, the enumerated list "a computer, a laptop, a PDA" does not imply that any or all of the three items of that list are mutually exclusive and does not imply that any or all of the three items of that list are comprehensive of any category.

[184] An enumerated list of items (which may or may not be numbered) does not imply that any or all of the items are equivalent to each other or readily substituted for each other.

[185] All embodiments are illustrative, and do not imply that the invention or any embodiments were made or performed, as the case may be.

VI. Computing

[186] It will be readily apparent to one of ordinary skill in the art that the various processes described herein may be implemented by, e.g., appropriately programmed general purpose computers, special purpose computers and computing devices. Typically a processor (e.g., one or more microprocessors, one or more micro-controllers, one or more digital signal processors) will receive instructions (e.g., from a memory or like device), and execute those instructions, thereby performing one or more processes defined by those instructions.

[187] A "processor" means one or more microprocessors, central processing units (CPUs), computing devices, micro-controllers, digital signal processors, or like devices or any combination thereof.

[188] Thus a description of a process is likewise a description of an apparatus for performing the process. The apparatus that performs the process can include, e.g., a processor and those input devices and output devices that are appropriate to perform the process.

[189] Further, programs that implement such methods (as well as other types of data) may be stored and transmitted using a variety of media (e.g., computer readable media) in a number of manners. In some embodiments, hard-wired circuitry or custom hardware may be used in place of, or in combination with, some or all of the software instructions that can implement the processes of various embodiments. Thus, various combinations of hardware and software may be used instead of software only.

[190] The term "computer-readable medium" refers to any medium, a plurality of the same, or a combination of different media, that participate in providing data (e.g., instructions, data structures) which may be read by a computer, a processor or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Transmission media include coaxial cables, copper wire and fibre optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infra-red (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[191 ] Various forms of computer readable media may be involved in carrying data (e.g. sequences of instructions) to a processor. For example, data may be (i) delivered from RAM to a processor; (ii) carried over a wireless transmission medium; (iii) formatted and/or transmitted according to numerous formats, standards or protocols, such as Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP, TDMA, CDMA, and 3G; and/or (iv) encrypted to ensure privacy or prevent fraud in any of a variety of ways well known in the art. [192] Thus a description of a process is likewise a description of a computer- readable medium storing a program for performing the process. The computer-readable medium can store (in any appropriate format) those program elements which are appropriate to perform the method.

[193] Just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of an apparatus include a computer/computing device operable to perform some (but not necessarily all) of the described process.

[194] Likewise, just as the description of various steps in a process does not indicate that all the described steps are required, embodiments of a computer-readable medium storing a program or data structure include a computer-readable medium storing a program that, when executed, can cause a processor to perform some (but not necessarily all) of the described process.

[195] Where databases are described, it will be understood by one of ordinary skill in the art that (i) alternative database structures to those described may be readily employed, and (ii) other memory structures besides databases may be readily employed. Any illustrations or descriptions of any sample databases presented herein are illustrative arrangements for stored representations of information. Any number of other arrangements may be employed besides those suggested by, e.g., tables illustrated in drawings or elsewhere. Similarly, any illustrated entries of the databases represent exemplary information only; one of ordinary skill in the art will understand that the number and content of the entries can be different from those described herein. Further, despite any depiction of the databases as tables, other formats (including relational databases, object-based models and/or distributed databases) could be used to store and manipulate the data types described herein. Likewise, object methods or behaviours of a database can be used to implement various processes, such as the described herein. In addition, the databases may, in a known manner, be stored locally or remotely from a device which accesses data in such a database.

[196] Various embodiments can be configured to work in a network environment including a computer that is in communication (e.g., via a communications network) with one or more devices. The computer may communicate with the devices directly or indirectly, via any wired or wireless medium (e.g. the Internet, LAN, WAN or Ethernet, Token Ring, a telephone line, a cable line, a radio channel, an optical communications line, commercial on-line service providers, bulletin board systems, a satellite communications link, a combination of any of the above). Each of the devices may themselves comprise computers or other computing devices that are adapted to communicate with the computer. Any number and type of devices may be in communication with the computer.

[197] In an embodiment, a server computer or centralised authority may not be necessary or desirable. For example, the present invention may, in an embodiment, be practised on one or more devices without a central authority. In such an embodiment, any functions described herein as performed by the server computer or data described as stored on the server computer may instead be performed by or stored on one or more such devices.

[198] Where a process is described, in an embodiment the process may operate without any user intervention. In another embodiment, the process includes some human intervention (e.g., a step is performed by or with the assistance of a human).

[199] It should be noted that where the terms "server", "secure server" or similar terms are used herein, a communication device is described that may be used in a communication system, unless the context otherwise requires, and should not be construed to limit the present invention to any particular communication device type. Thus, a communication device may include, without limitation, a bridge, router, bridge- router (router), switch, node, or other communication device, which may or may not be secure.

[200] It should also be noted that where a flowchart is used herein to demonstrate various aspects of the invention, it should not be construed to limit the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. Often, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the true scope of the invention. [201 ] Various embodiments of the invention may be embodied in many different forms, including computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer and for that matter, any commercial processor may be used to implement the embodiments of the invention either as a single processor, serial or parallel set of processors in the system and, as such, examples of commercial processors include, but are not limited to Merced™, Pentium™, Pentium II™, Xeon™, Celeron™, Pentium Pro™, Efficeon™, Athlon™, AMD™ and the like), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other PLD), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other means including any combination thereof. In an exemplary embodiment of the present invention, predominantly all of the communication between users and the server is implemented as a set of computer program instructions that is converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor under the control of an operating system.

[202] Computer program logic implementing all or part of the functionality where described herein may be embodied in various forms, including a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as Fortran, C, C++, JAVA, or HTML. Moreover, there are hundreds of available computer languages that may be used to implement embodiments of the invention, among the more common being Ada; Algol; APL; awk; Basic; C; C++; Conol; Delphi; Eiffel; Euphoria; Forth; Fortran; HTML; Icon; Java; Javascript; Lisp; Logo; Mathematica; MatLab; Miranda; Modula-2; Oberon; Pascal; Perl; PL/I; Prolog; Python; Rexx; SAS; Scheme; sed; Simula; Smalltalk; Snobol; SQL; Visual Basic; Visual C++; C#; Linux and XML.) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form. [203] The computer program may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g, a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM or DVD-ROM), a PC card (e.g., PCMCIA card), or other memory device. The computer program may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and inter-networking technologies. The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).

[204] Hardware logic (including programmable logic for use with a programmable logic device) implementing all or part of the functionality where described herein may be designed using traditional manual methods, or may be designed, captured, simulated, or documented electronically using various tools, such as Computer Aided Design (CAD), a hardware description language (e.g., VHDL or AHDL), or a PLD programming language (e.g., PALASM, ABEL, or CUPL). Hardware logic may also be incorporated into display screens for implementing embodiments of the invention and which may be segmented display screens, analogue display screens, digital display screens, CRTs, LED screens, Plasma screens, liquid crystal diode screen, and the like.

[205] Programmable logic may be fixed either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed disk), an optical memory device (e.g., a CD-ROM or DVD-ROM), or other memory device. The programmable logic may be fixed in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., Bluetooth), networking technologies, and internetworking technologies. The programmable logic may be distributed as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web).

[206] "Comprises/comprising" and "includes/including" when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. Thus, unless the context clearly requires otherwise, throughout the description and the claims, the words 'comprise', 'comprising', 'includes', 'including' and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

Claims

1 . A clinical workflow management system comprising:

a web based user interface comprising a single page application for displaying at least one clinical workflow;

at least one application programming interface comprising a REST compliant set of stateless operations, where the at least one application programming interface operates between the web based user interface and at least one data store; and,

a scalable data storage base comprising the at least one data store;

wherein the web based user interface is operatively associated with the scalable data storage base through a set of bounded contexts where each bounded context is associated with one of the application programming interfaces and one data store.

2. A method of operating a clinical workflow management system comprising one or a combination of the following steps:

associating each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores with a separate one of a plurality of bounded contexts;

sending system requests in order of importance and loading return data in order of their arrival;

storing the minimum necessary data for each context in its associated data store; storing a copy of data for peripheral actions in a queue to be processed asynchronously such that peripheral actions are performed separate to initiating and higher priority actions.

3. A method of displaying a unified contextual navigation in a clinical workflow management system comprising the steps of:

selectively presenting a plurality of display panels comprising items grouped by context.

4. A method as claimed in claim 3 wherein the display panels are selectively displayed in the form of a flex accordion where opening a panel displaces adjacent panels.

5. A method of checking patient information against an external provider in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of:

raising a request from a client application API upon opening a patient record through a client application user interface for checking patient information against an external provider database;

placing the request in a queue for further processing by a client application service acting as an interface between a client application API and a service provided by the external provider;

the client application service checking for a cached request that corresponds to the raised request;

returning a copy of a response matching the cached request from the client application service and stopping further processing of the raised request;

the client application service continuing processing of the raised request if there is no cached request by forwarding the request to the external provider;

the client application service forwarding any received response from the external provider to the client application to process including updating the patient details and/or notifying a user of the clinical workflow management system of the patient information.

6. A method of searching a patient's medical history in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: creating at least one artefact comprising clinical or other data created in the course of providing medical services to a patient;

storing the at least one artefact in at least one of the plurality of data stores;

indexing the at least one artefact by parsing its content, splitting content into tokens, processing tokens, and creating an index of each of the tokenised data;

entering a search query comprising search terms;

tokenising each entered search query term; and,

scoring stored indexes against the tokenised search query terms.

7. A method managing data in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of:

recording an action taking place during a medical consultation as tokenised data; creating at least one artefact corresponding to the recorded action and to be used as a proxy for the recorded action.

8. A method of managing data in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of:

creating at least one artefact comprising clinical or other data created in the course of providing medical services to a patient;

storing the at least one artefact in at least one of the plurality of data stores;

indexing the at least one artefact by parsing its content, splitting content into tokens, processing tokens, and creating an index of each of the tokenised data.

9. A method of synchronising communication between clients in a clinical workflow management system in which each of a plurality of interconnected API functions and/or methods and a corresponding one of a plurality of data stores is associated with a separate one of a plurality of bounded contexts, the method comprising the steps of: assigning categories to selected database tables in the plurality of data stores, the categories comprising one or a combination of user, center or patient;

sending a message to at least one application client in the event one of the tables is modified, the message comprising the type of message and an identification;

making an API call for retrieving all information if a relevant identification is received by an application client and in response;

the application client updates a user interface to match information on a server of the clinical workflow management system.

10. Apparatus adapted to operate a clinical workflow management system, said apparatus including: processor means adapted to operate in accordance with a predetermined instruction set,

said apparatus, in conjunction with said instruction set, being adapted to perform the method as claimed in any one of claims 2 to 9.

1 1 . A computer program product including:

a computer usable medium having computer readable program code and computer readable system code embodied on said medium for operating a clinical workflow management system within a data processing system, said computer program product including:

computer readable code within said computer usable medium for performing the method as claimed in any one of claims 2 to 9.

12. A method, process or protocol as herein disclosed.

13. An apparatus, system and / or device as herein disclosed.