In large organisations with multiple systems, a single shared repository is sometimes used to provide a central point for sharing information (typically in the form of documents). This generally performs two key roles:
- Provides a “registry” or list of the information (or documents) that are held about each patient. This typically incorporates some basic metadata to describe the items of information held in the repository. The registry can then be searched and queried based on specific patients or other items of metadata.
- Provides a “repository” of the information / documents, and a means to add, update and delete.
Any system can add documents to the repository, and will typically also provide the associated metadata about the document to update the registry. In some cases, this metadata could be extracted directly from the document itself.
- Allows for updates to be made in any system, but with a robust mechanism for ensuring that changes are disseminated to all systems as required.
- Does not remove the possibility of conflicting updates, but makes this much less likely than in an ad-hoc or manual solution.
- Pattern already supported by PSIS (document based) and PDS (granular demographic information).
- Would not easily scale beyond a local health community unless the central repository became a national shared repository. A shared repository could potentially be used to allow regional repositories to be linked up (see the Registry Repository pattern).
- Could potentially hamper system performance as a result of having to query a remote system whenever shared information needs to be accessed.
- Sharing policies (data sharing agreements) must be agreed by all parties.
Was this article useful?2