Publish registry metadata
Use this pattern when multiple integration teams need to discover what a registry offers before any record-level access is opened or a data sharing agreement is signed.
Starting situation
Section titled “Starting situation”A ministry of health operates a health facility registry covering 4,200 public and private facilities across twelve districts. Three external systems need to integrate: a supply-chain platform, a patient-referral router, and an audit tool from a donor programme. Each team asks the same questions before any integration work starts: What fields does the registry expose? Which facilities are in which districts? What access controls apply? The ministry wants one canonical place to answer those questions without opening record-level access first.
What you set up
Section titled “What you set up”Write profile fixtures that describe the registry: the publisher organization, the dataset, the data service, the access rules, the field schema, and any evidence offerings. Run Registry Manifest to render a static metadata bundle from those fixtures. The bundle can include a DCAT catalog, a JSON Schema for the facility record, an SHACL shape, and an ODRL policy document.
Publish the bundle to a static host or configure Registry Relay to expose the metadata artifacts alongside its protected consultation routes.
Registry Manifest handles the rendering. Registry Relay handles the runtime metadata endpoint, if you use one. Neither component requires you to open record access first.
What a caller does
Section titled “What a caller does”An integration team fetches the catalog document or navigates the published artifact links. They read the service description, check the schema for expected fields, review the policy document for access constraints, and identify which evidence offering matches their information need. They complete this inspection before requesting a data sharing agreement or writing client code.
What the caller gets back
Section titled “What the caller gets back”A set of static or hosted documents: a catalog record, a data service description, a JSON Schema, an SHACL shape, a policy document, and links to any evidence or requirement metadata. The caller sees what the registry describes itself as offering. They do not receive record-level data, and the published artifacts do not prove that any specific facility or entity exists in the source system.