Library

Browse and search developer information

Single Shared Application

Pattern Description

SharedApplication

In some local health communities, an existing centrally hosted clinical system is already in place and is used across a number of care settings. In this case, it is logical to make use of this shared system to share patient information across services in that community.

Such shared clinical systems are typically modular in nature, with the different modules being tailored for the workflows that exist in the specific care settings.

Data is (typically) shared via a common shared data store. Consistency in the information that is shared is often achieved by developing data-entry templates for specific information to be shared, and providing views of that information across the various care settings using the shared clinical system.

Benefits

  • Where a good proportion of the care settings in the locality already use a shared system, this can very quickly allow for sharing of records across those care settings.
  • By using an existing known system, the training, deployment and IG effort may be reduced.

Concerns

  • Scaling beyond a local health community is difficult using this approach as it relies on all services using the same system.
  • It is very unlikely that all care settings that would want access to patient information will be using a single shared system already – this may disenfranchise those who are told they have to use a new system.
  • Granting access to others not already using the shared system may be difficult. It may be possible for other care settings to use a record “viewer” to provide a read-only view of the record.
  • Updates to other EPRs would be manual, and any updates to the shared information would need to be fed back to a team with full access to the shared clinical system. This duplication could lead to inaccuracies and conflicting information across systems.
  • Can lead to vendor “lock-in”.