Littlefish will be developed on a multi user, cross platform basis so that a standard general clinical system will form the basis of the programme but will eventually allow individual users to modify the software to their particular requirements whether this be urban rural or remote areas.

Any changes would be the prerogative of the individual health service. Using the open source methodology we would require that changes to source code be contributed back into the source code pool so that others may benefit.

Product/Component Integration.

The components would be standard products so that the programme would work across all operating systems.

The initial project number would be 0.01.As new additions are made the version number will change (0.02, 0.03 etc) until the Status Version 1.0 is reached and the software is deemed by the user group as fit for general distribution.

Database content focused on diseases, treatment patterns, clinical outcomes, patient satisfaction and functionality measures, and treatment costs.

Support of analyses based on various entity types associated with each data element in the databases.

Access to data for analysis purposes will be subject to agreed upon rules and system-wide security authorisation requirements applied to each data element.

The database will be built on the object-oriented database design guidelines of the Good Electronic Health Record OBJECT Model

Any Object Orientated Language that fulfils the GEHR technical requirements. Examples: Java, Eiffel etc

Operating System.

Multiple operating systems : MS Dos, Windows , Linux ,Unix, Apple

MS Dos, Windows , Linux ,Unix, Apple

Suggested Operating Systems :

Linux is a free operating system and has excellent support services via the internet. The Operating System has well-established stability and reliability.

However  Littlefish will be written so that it operates across all platforms and no one operating system will be favoured

Littlefish will:

Support automated exchange of health care related clinical, financial, and administrative data.

Facilitate automated messaging and transaction management.

Utilise a distributed systems architecture model in which each organisation retains responsibility and control over its own internal data systems and databases.

In simple English this means that any health care organisation can use the software for its own internal use without releasing its private and confidential information to anyone else.

Support automated, system-wide transaction addressing and database querying

at any end-user system node through use of:

A common entity indexing system

A trusted querying and transaction authorisation system

Common network communications protocols

A network systems management facility.

Maintain specialised databases of clinical and operational data to support end-user transaction processing requirements, clinical and organisational benchmarking processes, and clinical and operational decision support applications.

Characteristics of  Littlefish  include:

Database content focused on diseases, treatment patterns, clinical outcomes, patient satisfaction and functionality measures, and treatment costs.

Support of analyses based on various entity types associated with each data element in the databases.

Access to data for analysis purposes will be subject to agreed upon rules and system-wide security authorisation requirements applied to each data element.

Databases built on object-oriented database designs that will interface with relatinal databases

System Standards.
Communications, transaction management, data element coding and syntax, and methods of entity identification will be based on standards already developed by national standards organisation such as the ISO and will be supplemented as needed by new guidelines to meet system requirements not yet addressed by these standards.

Gateways to External Knowledge Sets.
Gateways will be provided at any end-user node to public and private knowledge bases of clinical research, medical practice guidelines, educational resources, and other decision support tools as they become available.

Multimedia Capabilities.
Littlefish  will allow for the use of multimedia to support image, video, and audio-visual data exchange.

Remote Communications Capability.
Support for secure provider and patient communications and database access utilising personal computers and other personal communications devices from remote sites will become available through the system.

Littlefish   should include reasonable contingency arrangements and mechanisms to allow for continued operation of core system functions in the event of a major system failure, e.g.: a server or database crash. Ideally the solution should include provisions to allow core system functions to be performed in a stand-alone fashion (e.g.: say on a lap top) as an interim measure pending recovery of the main system.

A core element for system reliability will be the inclusion of remote data replication technology to enable core databases to be re-build with data stored off site on remote partner systems. This mechanism will allow for the automatic rebuilding of critical information in the event of hardware failure.

Ability to create/modify/delete comprehensive client records with relevant screen layouts and database definitions.

Littlefish would have any number of name fields and would be able to map relationships or family trees for viewing to ensure the correct identification of the patient. This is of great importance where an individual may be known legitimately by a number of names but in terms of patient identification can be a major problem.

Ability to prepare individual health plans based on standard recalls criteria and primary care guidelines and record full histories of client treatments/interventions and outcomes.

Ability to inquire or report on clients or groups of clients based on flexible selection criteria.

Littlefish  should provide flexible recall capabilities to allow for effective management and monitoring of health plans for individuals and groups of clients and support comprehensive and 'opportunistic' screenings and interventions for individuals and targeted groups, and an exception reporting/management mechanism to identify overdue interventions.

Littlefish  should provide flexible mechanisms to support activity and workload scheduling and recording/reporting on performance against these work plans.

Littlefish should provide a flexible activity reporting capability that will enable a Health Service to define and produce summaries of activities/services provided to the community as a whole in a format appropriate to their needs, to selected groups and to meet Government or Health Authority accountability requirements.

Littlefish   would provide a flexible general purpose inquiry and reporting facility to support ad-hoc data analysis, manipulation, aggregation etc.

Any statistical or other complex reporting capabilities will be available  or capable of being added to  Littlefish  .

Littlefish  would provide a flexible data extraction facility to allow user-defined selections or aggregations of data to be extracted from the system in a variety of formats.

Littlefish would allow third party products/tools to access or extract data from the system and the mechanism for this would be decided by the user at the local level. Additions of third party tools to the generic model would be on the proviso that the tools would not compromise the licence.

Littlefish  should provide a mechanism for the electronic transmission of data extracts to an approved third party should the need arise.

This would be achieved by the use of smart cards where the patient would provide a card and a password to the approved third party to view  the individuals information only. The third party would only be able to add data. No modifications to the parent data base would be allowed.

All system administration will be either automated i.e. backup and data replication or be governed by an internal rule base that can be tailored by the individual health care administrator.

Health Providers should describe any other key functions/capabilities of the proposed system they would like to see  over and above the core functional requirements listed above.

Because of the nature of the project the Health service will be able to either download the programme or purchase it on CD-ROM so they can evaluate it. As the programme is open source there are no restrictions on how it is distributed.

As indicated the proposed methodology would be on a collaborative open source model. Each individual health service would be able to develop the software in any way it sees fit. Requests for assistance would be met via other users through the newsgroups

The open source methodology capacity to deliver and support solutions to all locations across the globe (urban, rural and remote).

Help will be via mailing lists, newsgroups and the Pangaea Website

System modification / upgrade arrangements. will be via mailing lists, newsgroups FTP and the Pangaea Website.

The documentation for the Littlefish  system will also be developed in a collaborative basis. All facilities within the software shall provide the ability to access on-line documentation. Where the on-line help is unclear, feedback mechanisms mailing lists, newsgroups and the Pangaea Website will be built into the application to facilitate timely correction of the documentation.

return to homepage

FEEDBACK  Please click here to add your comments