ISO/TS 27790:2009 — Health informatics — Document registry framework

Introduction to ISO/TS 27790:2009

ISO/TS 27790:2009, “Health informatics — Document registry framework,” defines a reference architecture for registering, discovering, and retrieving healthcare documents across distributed systems. The framework is based on the ebXML Registry Information Model (ebRIM) and has been harmonized with the IHE Cross-Enterprise Document Sharing (XDS.b) integration profile. It provides the backbone for many national and regional health information exchanges worldwide, enabling clinicians to discover patient documents regardless of where those documents were originally created. Developed by ISO/TC 215, this Technical Specification addresses the fundamental challenge that healthcare documents are often scattered across multiple independent systems — hospital A’s EHR, specialist B’s practice system, pharmacy C’s dispensing records — and there is no simple way for a clinician at point of care to discover all relevant documents for a given patient.

The document registry framework separates the registry function (metadata management and document discovery) from the repository function (document storage and retrieval). This separation allows organizations to maintain local control over document repositories while participating in a federated registry network. The registry stores standardized metadata about each document — including patient identifier, document type, author, healthcare facility, service date, and confidentiality level — and returns repository locations in response to queries. Importantly, the registry does not store the actual document content, only the metadata, which simplifies security and privacy compliance (the registry itself contains no clinically sensitive data, only pointers to where such data resides).

The framework also defines a submission set concept for grouping related documents from a single encounter or episode of care. For example, all documents generated during a hospital admission (admission note, progress notes, nursing records, discharge summary) can be submitted as a set with shared metadata attributes. This grouping is preserved through subsequent queries, allowing clinicians to retrieve complete care episodes rather than requiring piecemeal document discovery.

Architecture and Metadata Model

The architecture defined in ISO/TS 27790:2009 consists of five principal actors: the Document Registry, the Document Repository, the Document Source (which submits documents), the Document Consumer (which queries and retrieves documents), and the Patient Identity Source (which provides patient identifier cross-referencing). These actors interact through standardized transactions defined in the accompanying IHE Technical Frameworks. The separation of concerns among these actors enables a modular deployment approach — organizations can start with a simple registry-plus-repository configuration and later add identity cross-referencing, community gateways, and audit trail capabilities as their interoperability requirements mature.

Implementation Patterns for Engineers

For system architects and engineers implementing ISO/TS 27790:2009, several design decisions significantly impact system performance and reliability. First, the choice of metadata database technology matters: relational databases (PostgreSQL, Oracle) offer robust ACID compliance and mature tooling, while NoSQL stores (MongoDB, Couchbase) provide better horizontal scalability for query-heavy workloads. Hybrid approaches that use a relational store for the registry and object storage (AWS S3, MinIO) for document repositories are increasingly common. The registry typically experiences a read-heavy workload (many more queries than submissions), so query optimization — particularly on the patientId, creationTime, and classCode attributes — is essential.

Second, document lifecycle management must account for replacement, transformation, and deletion. The standard defines a submission set concept that groups related documents (e.g., all reports from a single patient encounter). When a document is replaced (e.g., an amended radiology report), the registry marks the old entry as deprecated but retains it for audit trail purposes — a pattern similar to git commit history where old versions are preserved but the latest is clearly indicated. This approach ensures that clinical teams can always reconstruct the historical record while clearly seeing which version is current. The replacement chain is tracked through relationship attributes that link each document version to its predecessor and successor.

Third, cross-community document sharing requires resolving patient identity across affinity domains. The Patient Identity Source actor in the framework handles cross-referencing using either deterministic matching (exact identifiers) or probabilistic matching (demographic similarity scoring). Engineers should implement configurable match thresholds and manual review queues for borderline cases. The standard also recommends a “patient identity feed” mechanism that proactively distributes identity updates to all connected communities, reducing the likelihood of query failures due to stale patient identifiers.

Frequently Asked Questions