Frameworks and methodologies configured to enable design and implementation of customised clinical information systems, enable native interoperability between customisable clinical information systems, enable process efficiency management in clinical information systems

Described herein are relates to frameworks and methodologies configured to enable design and implementation of customised clinical information systems. One embodiment includes a computer implemented method for providing Clinical Information System (CIS) functionalities, the framework including: providing a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes: (i) content pages, wherein each content page is configured to contain one or more page objects; and (ii) logical rules defining navigation and behaviour of content pages; providing access to a common central patient information database; providing a content and process design user interface, thereby to enable a user of a client terminal to define, by way of a graphical Interface, CIS interface design data; and operating a content and process engine.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a U.S. National Phase of International Patent Application Serial No. PCT/AU2015/000352, entitled “FRAMEWORKS AND METHODOLOGIES CONFIGURED TO ENABLE DESIGN AND IMPLEMENTATION OF CUSTOMISED CLINICAL INFORMATION SYSTEMS, ENABLE NATIVE INTEROPERABILITY BETWEEN CUSTOMISABLE CLINICAL INFORMATION SYSTEMS, ENABLE PROCESS EFFICIENCY MANAGEMENT IN CLINICAL INFORMATION SYSTEMS AND/OR ENABLE IMPLEMENTATION OF INDEPENDENT FORMAL ONTOLOGY VALUES IN CUSTOMISED CLINICAL INFORMATION SYSTEMS,” filed on Jun. 16, 2015. International Patent Application Serial No. PCT/AU2015/000352 claims priority to Australian Patent Application No. 2014902286, filed on Jun. 16, 2014; and to Australian Patent Application No. 2014902288, filed on Jun. 16, 2014; and to Australian Patent Application No. 2014902290, filed on Jun. 16, 2014; and to Australian Patent Application No. 2014902294, filed on Jun. 16, 2014; and to Australian Patent Application No. 2014902296, filed on Jun. 16, 2014. The entire contents of each of the above-cited applications are hereby incorporated by reference for all purposes.

FIELD OF THE INVENTION

The present invention relates to frameworks and methodologies configured to enable design and implementation of customised clinical information systems. Some embodiments have been particularly developed for providing a hybrid between best-of-breed architecture and enterprise architecture, thereby to allow a clinical environment to leverage advantages associated with each. Some embodiments have been developed to enable native interoperability between customisable clinical information systems. Some embodiments have been developed to enable process efficiency management in clinical information systems. Some embodiments have been developed to enable implementation of independent formal ontology values in customised clinical information systems.

While some embodiments will be described herein with particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.

BACKGROUND

Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.

The use of Clinical Information Systems (CIS) has become popular in contexts such as managing patient information and workflows. There are two broad categories of software that has been used to provide such systems:Customized tailor made software (also known as “best-of-breed” software) which is custom developed for a particular implementation or situation. This is advantageous, in the sense that there is scope of case-specific tailoring. However, there are typically high development overheads, and challenges in integrating with other systems.Enterprise software, which is implemented across a facility. This also comes with its advantages, particularly by reference to a broad range of functionalities that are often provided with relatively expansive software products, however there are inherent challenges in dealing with specific situations due to lack of customisation.

Furthermore, both approaches traditionally suffer from deficiencies in the sense that processes and procedures (and hence business requirements) develop and change over time, whilst software updates and modifications can be slow to keep up thereby to accommodate for such developments and changes.

SUMMARY OF THE INVENTION

One embodiment provides a computer implemented method for providing Clinical Information System (CIS) functionalities, the framework including:

providing a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more page objects; and

(ii) logical rules defining navigation and behaviour of content pages;

providing access to a common central patient information database, wherein the plurality of purpose specific CIS interfaces each have direct read and write access the common central patient information database;

providing access to a common Patient Administration System (PAS), wherein the plurality of purpose specific CIS interfaces each have direct native access to functionalities provided the common PAS;

providing a content and process design user interface, thereby to enable a user of a client terminal to define, by way of a graphical Interface, CIS interface design data; and

operating a content and process engine configured to, based upon interaction between the client terminal and content and process design user interface, define content and process data for enabling rendering of a plurality of custom CIS user interfaces at distributed client terminals.

One embodiment provides a computer implemented framework for providing Clinical Information System (CIS) functionalities, the framework including:

a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

a common central patient information database, wherein the plurality of purpose specific CIS interfaces each have direct read and write access the common central patient information database.

One embodiment provides a computer implemented framework for providing Clinical Information System (CIS) functionalities, the framework including:

a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

a common Patient Administration System (PAS), wherein the plurality of purpose specific CIS interfaces each have direct native access to functionalities provided the common PAS.

One embodiment provides a computer implemented method for providing Clinical Information System (CIS) functionalities, the method including:

providing a content and process design user interface, thereby to enable a user of a client terminal to define, by way of a graphical Interface, CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more customisable page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

operating a content and process engine configured to, based upon interaction between the client terminal and content and process design user interface, define content and process data for enabling rendering of a plurality of custom CIS user interfaces at distributed client terminals.

One embodiment provides a computer implemented method for providing Clinical Information System (CIS) functionalities, the method including: enabling a user to generate CIS content data via a graphical content editing platform; and hosting the generated CIS content data thereby to allow a further user to interact with a CIS rendered based on the generated CIS data.

One embodiment provides a computer implemented method for providing Clinical Information System (CIS) functionalities, the method including:

providing a content and process design user interface, thereby to enable a user of a client terminal to graphically define CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more customisable page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

maintaining data indicative of a plurality of distinct CIS interfaces defined via the content and process design user interface;

enabling a user to customise a first customisable page object by:

(a) selecting a second customisable page object; and

(b) setting a rule to use a value associated with a current user in respect of the second customisation page object.

One embodiment provides a computer implemented framework for providing Clinical Information System (CIS) functionalities, the framework including:

a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

a monitoring engine configured to collect data representative of user interaction with each CIS interface, thereby to enable determination of process efficiency.

One embodiment provides a computer implemented method for providing Clinical Information System (CIS) functionalities, the method including:

providing a content and process design user interface, thereby to enable a user of a client terminal to define, by way of a graphical Interface, CIS interface design data, wherein the CIS interface design data includes:

(i) content pages, wherein each content page is configured to contain one or more customisable page objects; and

(ii) logical rules defining navigation and behaviour of content pages; and

wherein the user interface enables a given object to be associated with a formal value defined in an independent formal ontology.

One embodiment provides a computer program product for performing a method as described herein.

One embodiment provides a non-transitive carrier medium for carrying computer executable code that, when executed on a processor, causes the processor to perform a method as described herein.

One embodiment provides a system configured for performing a method as described herein.

As used herein, the term “exemplary” is used in the sense of providing examples, as opposed to indicating quality. That is, an “exemplary embodiment” is an embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality.

DETAILED DESCRIPTION

Described herein is technology including frameworks and methodologies configured to enable design and implementation of customised clinical information systems (CIS).

Some embodiments have been particularly developed for providing a hybrid between best-of-breed architecture and enterprise architecture, thereby to allow a clinical environment to leverage advantages associated with each. Some embodiments have been developed to enable native interoperability between customisable clinical information systems. Some embodiments have been developed to enable process efficiency management in clinical information systems. Some embodiments have been developed to enable implementation of independent formal ontology values in customised clinical information systems.

Various exemplary embodiments are discussed below.

General Overview

Embodiments described below relate to the provision of multiple Clinical Information System interfaces via a common framework. For example, a given healthcare facility may have individual CIS relating to the likes of oncology, emergency, radiology, colonoscopies, and so on.

The term “Clinical Information System” (referred to herein, in singular or plural, using the abbreviation CIS) describes a software-based product (i.e. a product that performs one or more computer executable methods via the execution of computer readable code using one or more processors) which provides functionality relevant to a clinical environment. This is used interchangeably with “CIS interface”. The term “CIS user interface” describes a user interface rendered at a client terminal thereby to provide functional access to a given CIS. For example, a CIS user interface may be rendered in a web browser application, which downloads CIS interface design data from a server, or proprietary “parent” software application, which is able to load any one of multiple available CIS interfaces as functionally executable files.

The term “CIS interface design data” describes data indicative of CIS user interface components (such as pages and objects) and underlying logic, which is generated by a user, and enables the rendering of a CIS user interface.

A given CIS typically provides one or more “workflows”. A workflow is a series of steps that are followed, for example involving data entry, thereby to assist in monitoring and/or management of clinical procedures and activities. For example, a workflow may be completed via the entry of information into a plurality of electronic forms. As described herein, these electronic forms are defined on “content pages”. Each content page is configured to contain one or more page objects, such as:Information objects (for example text-based data, such as a question or prompt, image data, video data, and so on).Interactive buttons (for example a “submit” button, “next page” button, and so on).Data fields, which are configured to contain values. These values may be user inputted, or automatically determined (for example as default values, calculated values, or values obtained from a specified source based on defined logic/rules).

It will be appreciated that this is a very basic selection of exemplary page objects only, and that a wide range of page objects may be present (for example using page objects known form general web page technology).

A workflow is additionally associated with logical rules defining navigation and behaviour of content pages. For example these define an order in which pages are completed (which may vary depending on observed values), allowable values for certain data fields, mandatory/optional statuses for certain data fields, and so on.

Various embodiments considered below provide a content and process design user interface, thereby to enable a user of a client terminal to graphically define CIS interface design data. For example, this content and process design user interface allows a user to create custom workflows. This is achieved by user-generation of content pages and logical rules. Preferably the content and process design user interface provides a selection of generic customisable page objects (for example buttons, data fields, and information objects). A user is enabled to place these onto a content page (for example using a “drag and drop” or other approach) and customise the objects by setting one or more parameters. Customisation may be achieved by providing access to, for a given object, a customisation menu which allows setting of parameters. This setting of parameters additionally allows for defining of logical rules. This provides a very user-friendly CIS generation tool, allowing for the creation and modification of workflows without any special software development and/or coding skills.

Each individual CIS leverages a common overall software infrastructure, for example leveraging a common set of patient management systems and databases. In this manner, general overarching CIS functionalities, which are required for all CIS systems (for example patient admission) are centralised and available to be shared. Accordingly, each individual CIS need only be concerned with its specific workflows that are relevant to the particular situation for it is designed. This provides advantages of “best-of-breed” software, in that each CIS is custom tailored for specific situations, (optionally be extremely specific in nature), whilst retaining overall infrastructural advantages typically associated with enterprise software.

Exemplary Framework

FIG. 1illustrates a framework according to one embodiment. In overview, this framework provides CIS functionality to a plurality of client terminals100, which may be substantially any form of computing devices (for example PCs, notebooks, tablets, smartphones, and so on). These client terminals may access CIS functionalities in two main ways:Generation and/or modification of CIS interfaces (such as in the case of exemplary client terminal101). As described further below, this is achieved by way of a content and process design tool user interface130. User interface130may be provided, for instance, by way of a browser-based arrangement (user interface data is rendered via a web browser), or via a proprietary standalone software application.Rendering of CIS user interfaces (such as in the case of exemplary client terminal102), thereby to provide a user with access to workflows associated with a given CIS. This may be achieved by way of a browser-based arrangement (whereby CIS interface design data is rendered via a web browser thereby to provide a CIS user interface), a “parent” software approach (whereby CIS interface design data is rendered via a proprietary software application specially configured to load such data) or via multiple standalone software applications.

Common systems110provide each of the custom designed CIS interfaces with native access to common functionalities, including the likes of PAS, analytics, and the like. That is, a suite of common functionalities required by a CIS are inherently natively available for each custom CIS120as a result of common systems110.

Common systems110, custom designed CIS interfaces120, and user interface130are illustrated as client side components, in the sense that they provide functionality that is accessed by client devices100. On the opposed server side there is provided a composite CIS management system150, which may be defined by a single server, or by multiple (optionally distributed) server and/or other computing components.

System150provides back-end support to the various client side components. For example, common systems engines151provide server side functionality relating to patient management and the like, whilst content and process engine152provide service side functionality relevant to user interface130. Code for enabling execution of custom CIS interfaces120is maintained in a content and process data repository154(also referred to as a CIS data repository, discussed in more detail further below).

A patient data repository153maintains data associated with each of a plurality of patients. This data includes details defined during patient registration (for example via a PAS included in common systems151), and data defined by the operation of any one or more of CIS interfaces120. That is, as a CIS interface is used, that may result in new data values being associated with a patient. Hosting all of this data in a common patient database is particularly valuable in the context of intra-CIS data sharing. Aspects of such data sharing are discussed in detail further below by reference to native interoperability.

Relational data store155is illustrated to graphically represent a single relational database that includes both patient data153and content/process data154.

Data repositories153-155may be defined by any number of discrete database components, and are illustrated as three separate discrete database as an example only.

System150also provides external interaction modules156, which enable interaction with external systems170(such as other software applications, databases, and the like). This may include interaction by way of APIs and/or by predefined interaction protocols, such as Health Level 7 (HL7) Standards or the like.

CIS Content Generation and Hosting

As shown inFIG. 1, content and process design user interface130operates in conjunction with a content and process engine152. Engine152is configured to, based upon interaction between a given client terminal and user interface130, define content and process data for enabling rendering of a custom CIS user interfaces at any of client terminals100. More specifically, interaction with interface130causes engine152to generate CIS data, this CIS data being indicative of user-generated (or user-modified) content pages (and hence also logical rules defining navigation and behaviour of content pages, with those ruled being defined by customisation of page objects).

In the present embodiment, CIS data is maintained in a CIS data repository154. In a preferred embodiment, this data is defined in XML format, for example defined in terms of page types, page objects, and page object parameters. CIS data (and hence CIS interfaces) are loaded from repository154and rendered as user interfaces on-demand. In this manner, each time a CIS interface is accessed by a client terminal100(or each time a given workflow is accessed), it is loaded from current CIS data. This allows modifications made to workflows to be made live substantially immediately.

An overall process flow according to an embodiment is illustrated in method200ofFIG. 2A. A user generates CIS data (which may include generating a new CIS/workflow/page, or modifying an existing CIS/workflow/page) at201. Then, upon completion of201, repository154is updated at202. Then, at203, a CIS interface is loaded (for example by downloading of code to enable rending of used interface components for one or more pages) by a client based on up-to-date CIS data from repository154.

FIG. 2Aalso illustrates a looped process204, which generally represents the updating of available page objects. As context, when a user selects a new page object for inclusion in a page, that is selected from a set of available customisable page objects (defined in repository158). That set is updated on an ongoing basis, for example where a new form of page object requires development to solve a particular problem.

In relation to content generation, user interface130allows a user to either commence generation of an existing CIS interface, or modify an existing CIS interface (for example by modifying a particular workflow).

When a page (either new or existing) is opened in interface130, a user is enabled to select an existing object, or add a new object of desired type (from the set of available customisable page objects). As noted, page objects may include the likes ofInformation objects (for example text-based data, such as a question or prompt, image data, video data, and so on).Interactive buttons (for example a “submit” button, “next page” button, and so on).Data fields, which are configured to contain values. These values may be user inputted, or automatically determined (for example as default values, calculated values, or values obtained from a specified source).

A user selects or adds an object at211, and opens an object parameter setting interface (for example by double-clicking the object). The parameter setting interface provides a menu for allowing access to and setting of object parameters. These may include:Visual parameters, such as font, colour, etc. Visual parameters such as size and position may in some cases be set graphically outside of the menu using drag/drop and stretch manipulations.For information objects, the information that is to be displayed.For interactive buttons, the function of the button (for example “submit”, “next page”, “previous page”, and so on).For data fields, the nature of data to be inputted (for example whether it is a date, time, value, etc), allowable value ranges, selectable values (for example if there is a drop-down menu), default values, pre-populated values, rules (for example whether a value is mandatory) and so on.Semantic definitions of the fields using an established terminology, classification or ontology and a value set defining the range of values the field can be assigned. For example, these may allow the embedding of a standardised semantic definition in an object as a property of the object, for example using data drawn from a known published formal ontology (such as SNOMED CT). This allows objective categorisation of data based on independent standards.Tables of data collated from information already stored about the patient.

FIG. 4AtoFIG. 4Dprovide sample screenshots from an embodiment of user interface130, showing various views relevant to customisation of page objects and the like.

In some cases logical rules may be defined for a data field, for example using IF, THEN, and ELSE logical operators. For example, in some cases a data field is set to be pre-populated with a value from patient database153. If the data is not available, that may indicate that another workflow needs to be completed, and a rule is set to launch that workflow.

As foreshadowed above, in some embodiments the user interface enables a given object to be associated with a formal value defined in an independent formal ontology (such as SNOMED CT, or another ontology). Preferably, the user interface provides a search functionality thereby to assist a user in identifying the formal value based on one or more user generated object parameter values.

Native Interoperability

As noted, some cases, a data field is customized to be pre-populated with a value, for example a value from patient database153. More broadly, various page objects may be configured to reference values in patient database153for a variety of reasons beyond display (for example to perform calculations, in the context of an “IF” operation, and so on).

Some embodiments implement a functionality referred to as native interoperability, which in essence allows for streamlined data sharing between CIS interfaces. In particular, this includes enabling a user to customise a first customisable page object by: (i) selecting a second customisable page object; and (ii) setting a rule to use a value associated with a current user in respect of the second customisation page object. For example, in a simple case this involves setting a data field to display a value that had previously been inputted via a data field in another CIS interface.

A key point is that the values are not defined by reference to specific database address codes. Rather, values are associated with the CIS interface, page, and page object from which they originate. In this manner, a user generating page content need not be familiar with database structure. They simply need to know in which workflow a value of current interest is inputted, and identify the page object via which it is inputted.

FIG. 2Billustrates an exemplary method200for utilising native interoperability. At211a user adds a new page object, or selects an existing page object. A parameter setting interface is opened at212(for example via a double click). At213a user makes a selection to rely on a referenced value, then identifies the relevant CIS (214), CIS form (and form page, where a given form spans multiple pages) (215) and page object (216). Referencing parameters are completed at217.

CIS Content Sharing

In a similar vein to native interoperability, in some embodiments a user is enabled to insert pre-customised page objects that already exist on other pages (for example in other CIS interfaces). In this regard, repository154provides a library of customised content that may be leveraged in future content generation thereby to streamline procedures.

Process Efficiency

Some embodiments provide a methodology and mechanisms of Continuous Process Improvement (CPI). This is a critical aspect of work in busy departments. This includes providing “native analytics” on the data in the integrated architecture. This allows, for example:(i) Analysis of work processes to identify the current costs (for example in the context of time overheads).(ii) Immediate “on-the-spot” changeability to introduce a new work practice (for example based on an alteration to one or more CIS user interface pages, or one or more user interface components provided on a given CIS user interface page).(iii) Analysis of the new work practices to determine if they did indeed introduce intended/anticipated improvements.(iv) Ability to either continue with new practices, or alternately revert to old practices vie “on-the-spot” changeability.

In this manner, embodiments of the overall CIS technology described herein contain a mechanism for analysing the usability features of various defined operational workflows. This enables “native usability metrics and measurement”; at any time a given staff member is enabled to view and analyse how he/she uses (and/or other users use) a given CIS. For instance, in some cases this includes how often he/she moves (and/or how often other users move) in a path from screens A to B to C and the time spent on each screen). One user may spend four times longer flipping between one screen and another than others, but if piece of data were to be moved from one screen to another you would speed up the workflow. The described framework is configured to enable a rapid primary assessment, quickly and cheaply change a given CIS (e.g. a CIS page or rule), do the reassessment by looking up some automatically collected reporting tables and reinstate the old process immediately if needs be.

In this regard, one embodiment provides a computer implemented framework for providing Clinical Information System (CIS) functionalities, the framework including: a plurality of purpose-specific CIS interfaces, wherein each interface is renderable at a given client terminal based on CIS interface design data, wherein the CIS interface design data includes: (i) content pages, wherein each content page is configured to contain one or more page objects; and (ii) logical rules defining navigation and behaviour of content pages; and a monitoring engine configured to collect data representative of user interaction with each CIS interface, thereby to enable determination of process efficiency. The data representative of user interaction preferably includes data representing time taken for each of a plurality of users to complete a given workflow defined by one or more content pages. The framework is preferably configured to provide a comparison of data representing time taken to complete a given workflow, according to a first workflow configuration, with representing time taken to complete the same workflow according to a second workflow configuration.

In some embodiments, methods and functionalities considered herein are implemented by way of a server, as illustrated inFIG. 3. In overview, a web server302provides a web interface303. This web interface is accessed by the parties by way of client terminals304. In overview, users access interface303over the Internet by way of client terminals304, which in various embodiments include the likes of personal computers, PDAs, cellular telephones, gaming consoles, and other Internet enabled devices.

Server303includes a processor305coupled to a memory module306and a communications interface307, such as an Internet connection, modem, Ethernet port, wireless network card, serial port, or the like. In other embodiments distributed resources are used. For example, in one embodiment server302includes a plurality of distributed servers having respective storage, processing and communications resources. Memory module306includes software instructions308, which are executable on processor305.

Server302is coupled to a database310. In further embodiments the database leverages memory module306.

In some embodiments web interface303includes a website. The term “website” should be read broadly to cover substantially any source of information accessible over the Internet or another communications network (such as WAN, LAN or WLAN) via a browser application running on a client terminal. In some embodiments, a website is a source of information made available by a server and accessible over the Internet by a web-browser application running on a client terminal. The web-browser application downloads code, such as HTML code, from the server. This code is executable through the web-browser on the client terminal for providing a graphical and often interactive representation of the website on the client terminal. By way of the web-browser application, a user of the client terminal is able to navigate between and throughout various web pages provided by the website, and access various functionalities that are provided.

Although some embodiments make use of a website/browser-based implementation, in other embodiments proprietary software methods are implemented as an alternative. For example, in such embodiments client terminals304maintain software instructions for a computer program product that essentially provides access to a portal via which framework100is accessed (for instance via an iPhone app or the like).

In general terms, each terminal304includes a processor311coupled to a memory module313and a communications interface312, such as an internet connection, modem, Ethernet port, serial port, or the like. Memory module313includes software instructions314, which are executable on processor311. These software instructions allow terminal304to execute a software application, such as a proprietary application or web browser application and thereby render on-screen a user interface and allow communication with server302. This user interface allows for the creation, viewing and administration of profiles, access to the internal communications interface, and various other functionalities.

Discussion of Advantages

Technology described herein provides for multiple individually designed CISs to run from the one server. Each CIS is designed by its own clinical team but installed to run on a joint server within the one version of the technology described herein. Each system has direct access to data in any other system where permission is provided, so that the records of the same patient being served by different clinical specialties can be directly accessed. Data fields in the one system can be set up to read from data input fields in another CIS. This approach removes the need for setting up message passing methods for exchanging data between the systems.

The effect is that each system can be developed independently yet the data they capture can be available to other CISs as and when it is needed without any other manual intervention.

This approach is particularly suited to research teams who need to build their own systems but also need a window into the records maintained by the clinical team. Instead of retrieving the paper record or visiting a distant site to view a record on a local computer the data is transported instantly to the research team the moment it is captured at the source point.

Technology described herein is based on knowledge that Clinical Information Systems are dynamic and need to evolve under the influence of a number of values, such as:Evaluation and subsequent revision of work processes;Changes in professional best practice;New requirements introduced by professional judgement;Introduction of research activities;Movement of personnel.

An optimal methodology will facilitate the client's changes as a result of the above influences. It also acts to ensure that work practices are given their true value. This is achieved through evidence gleaned from the collection and analysis of appropriate data. Subsequently, the client's CIS should be changeable so that the appreciated value of newly devised work practices is implemented into the system as soon as they are defined. The CIS should then enable the new collection practices to be readily learnt and absorbed by the workforce. In this way, the CIS is both the Servant of Change and the Mechanism of Change without being the Director of Change whilst serving in the supply of value. It is through this evolutionary process that progress with successful IT will advance in a constructive and productive manner. It will be seen as positively constructive in creating valued change instead of the negative destructive wrecking of current good practices with the introduction of ill-suited IT.

A popular idea that by making clinical practices go digital will automatically bring process enhancements and efficiencies is one of the untenable assertions about e-Health.

Most current Health IT software electronically mechanises existing processes, but due to their inflexibility future evolution of the CIS is made more, not less, difficult.

Technology described herein, according to some embodiments, avoids the above traps in a number of ways:Its approach to the analysis of the clinical processes allows for the current healthcare process to be absorbed into the designed system;The systematic analysis of the current process that goes into producing a CIS as described herein forces clinicians, and data and business managers to reflect on current practice and encourages both innovative and evolutionary reform;The adaptability of the technology described herein, which enables rapid changes to the design of systems, provides value in experimenting with different designs to optimise workable solutions;The native interoperability within the technology described herein can save clinicians and associate scientists significant time in data entry, retrieval and review, as well as exporting better quality data to third parties involved in care and to external agencies; and,The inherent plasticity of technology described herein allows the IT to follow modifications in patient care and to facilitate an audit as well as clinical and translational research.Technology described herein provides systems that are compact because they use the most advanced configurations of programming languages and multi-core processors. Modern technology allows for much more rapid transition to ever improving techniques in software engineering that better exploits the lower cost hardware that has come on to the market in the last 5 years. Larger and older ERP systems cannot move fast enough to exploit these technologies and therefore cannot bring down their costs nor deliver products that are so polished and well-tuned to clinicians needs.

Technology described herein can reproduce the client's current system and provide a number of other advantages to the current configuration, such as:Data Validation—better validation of data as its input ensures more reliable data analytics.Data Audit—technology described herein provides mechanisms for recording all activity of accessing screens and recording data, and so enables an audit of all user activity.Data Extraction—technology described herein has a variety of tools for increasingly complex data extraction. At the simplest level, it has the capacity to extract any tabular information as CSV or XML files by using mechanisms for exporting forms. This comes as an intrinsic function without any need for programming.Auto-coding of data according to SNOMED CT. Other coding schemes can be used where needed. This will create significant efficiencies for the medical record coding as required for statutory reporting.Data Analytics—data analytics services will enable better analysis of the existing data. More complex levels of data analytics are available through the CliniDAL suite in the form of ad hoc questioning, hypothesis testing, concept based searching of text fields and predictive modelling.The most advanced level is the development of predictive models to utilise the full value in any existing minimum dataset in order to identify the variables that best predict outcomes and then to apply them for prognostic purposes. This approach has been used previously for the Society of Plastic Surgeons on their breast implant database to identify the effectiveness of their minimum data set for predicting patient outcomes.Automatic loading of data into a registry. technology described herein is able to be HL7-compliant, so any registry which can receive HL7 messages can be automatically loaded with the data from a compatible CIS.Application Program Interfaces (APIs) are available to directly access system and patient data without needing to use messaging encoding and decoding processes. This mechanism is particularly useful for viewers that need to collect data from multiple system and then integrate the display of a unified patient record.
Conclusions and Interpretation

It will be appreciated that the disclosure above provides various significant frameworks and methodologies configured to enable design and implementation of customised clinical information systems

The methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a sound output device, and a network interface device. The memory subsystem thus includes a computer-readable carrier medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer-readable carrier medium carrying computer-readable code.

Furthermore, a computer-readable carrier medium may form, or be included in a computer program product.

In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a user machine in server-user network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

Thus, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program that is for execution on one or more processors, e.g., one or more processors that are part of web server arrangement. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium, e.g., a computer program product. The computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium.

The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term “carrier medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “carrier medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term “carrier medium” shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media; a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that, when executed, implement a method; and a transmission medium in a network bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions.