A Hospital Knowledge Graph: Wikidata Items, Organization IDs and sameAs Consistency

This article is for web engineers, SEO leads and digital heads at hospital groups: a brand with several branches, many departments and hundreds of doctors. It treats your public presence as a small knowledge graph, a set of entities and relationships that machines can read, and shows how to build one deliberately instead of letting it assemble itself from inconsistent pages.

It extends the general idea of entity consistency into implementation. You will see which identifiers to collect, how to model branches and departments in schema.org, where Wikidata fits and where it does not, and how to audit the result. The content is technical. It assumes you can edit templates and structured data and that a clinical and legal reviewer can approve the public facts. Nothing here guarantees a Knowledge Panel, a Wikipedia article or a place in any AI answer.

Why model it at all

A hospital group presents the same facts in many places: the corporate site, branch pages, doctor pages, Business Profiles, LinkedIn, directories, press articles, accreditation lists and Wikipedia or Wikidata if they exist. When these disagree, a system has to guess which facts apply to which entity. Disagreements are common: a branch named differently on the site and in Maps, a department listed under two parents, a doctor attached to the wrong location.

A knowledge graph approach fixes the facts first. You decide what the entities are, give each a stable identifier and write down the relationships once. Every publishing surface then draws from that record.

Step 1: The entity register

Create a spreadsheet or database table with one row per entity. For a hospital group, the types are:

• the group (the brand and legal entity)
• each hospital or branch
• each department at a branch
• each doctor
• optionally each service or procedure you want to be known for

For each entity, record:

Treat the register as the single source for templates, feeds and profile updates. If it is not in the register, it does not go on a profile.

Step 2: Model it in schema.org

The Hospital type sits under MedicalOrganization, Place and LocalBusiness paths, and supports the properties you need: department, parentOrganization, subOrganization, availableService, medicalSpecialty and identifier. Note that schema.org states parentOrganization supersedes the older branchOf.

A workable pattern:

• On the corporate homepage or about page, publish one Organization node for the group with name, legalName, url, logo, sameAs and a subOrganization list pointing to the branch URLs.
• On each branch page, publish a Hospital node with a stable @id (a URL with a fragment, such as the branch URL followed by #hospital), parentOrganization referencing the group's @id, address, geo coordinates, telephone, opening hours and sameAs for that branch's own profiles.
• On each department page, publish a node for the department with @id, a link to its branch and medicalSpecialty where it fits.
• On each doctor page, publish a Physician node with hospitalAffiliation referencing the branch @id.

Stable @id values are the point. They let the same entity be referenced from several pages without duplicating or contradicting it.

Google's Organization structured data documentation lists sameAs, legalName, iso6523Code, leiCode, taxID, url and logo among recommended properties and says some are "used behind the scenes to disambiguate your organization from other organizations." No property is required. Use the identifiers that you actually have: a registered legal name and tax ID for the group are normal, while an LEI is rare for hospitals and should not be invented. For markup background see our healthcare schema implementation guide.

The sameAs definition on schema.org is a "URL of a reference Web page that unambiguously indicates the item's identity." Treat that literally. Link the hospital's own LinkedIn page, Business Profile or Wikidata item. Do not link a generic directory category page, a competitor's page or anything that describes a different entity.

Step 3: Where Wikidata fits

Wikidata is a free, structured database. It has its own notability criteria: an item needs a valid sitelink to a Wikimedia project, or must refer to a clearly identifiable entity that can be described using serious, publicly available references, or must fulfil a structural need. A well-documented hospital group can meet the second test, and a branch might, depending on references.

Practical guidance:

1. Search first. Many large hospitals already have items. Do not create duplicates.
2. Check what exists. Review the labels, descriptions and statements for accuracy.
3. Use properties with care. Typical statements for a hospital include instance of (P31), official website (P856), parent organization (P749) and coordinates, each with a reference. The official website property page advises adding a new preferred statement when a homepage changes and keeping the old one.
4. Add references. Statements with a reliable reference are more durable than bare claims.
5. Respect conflict-of-interest norms. Edits by people connected to the subject should be disclosed and limited to factual, referenced corrections. Do not mass-create items for doctors or departments. Most will not meet notability or structural-need tests, and unreferenced promotional items get deleted.
6. Link both ways. If an item exists, add its URL to your organisation sameAs, and make sure the item lists your official website.

For doctors, similar rules apply. Wikidata has an identifier property for ORCID iD (P496) and one for the Google Knowledge Graph ID (P2671). The latter is described as the identifier used by the Google Knowledge Graph API, starting with "/g/". Their existence is not a reason to create items for individual doctors.

Step 4: Google, LinkedIn and the rest

Not every surface is editable by schema. Make a short list and assign an owner to each:

• Google Business Profile per branch. Exact name, primary category, address and hours as per the register. Do not stuff keywords into names.
• LinkedIn company page for the group, with branch locations if the platform supports them, and consistent description text.
• Directories and accreditation bodies. List each and note what ID they use for you.
• Hospital doctor directory. The one page per doctor that every other profile links back to.

When a hospital is renamed, merged or rebranded, update the register first, then run changes through every surface in the same week. Redirect old URLs and keep the old name as an allowed variant for a period.

Step 5: Consistency audit

Run this quarterly on a sample, and fully once a year.

1. Crawl your site and extract all JSON-LD nodes. Check that every @id is unique, every referenced @id exists and every branch has exactly one parent.
2. Compare names, addresses, phone numbers and coordinates in markup against the register and against Business Profiles. Log mismatches by type.
3. Check sameAs targets: each URL resolves, belongs to the correct entity and is not redirected to a generic page.
4. Check Wikidata items for vandalism or stale statements.
5. Observe outputs. Build 50 queries covering the group name, each branch name, each department and 10 doctor names. Run them on the AI and search surfaces you care about, on two different days. Log whether the entity is recognised, which facts are shown and which are wrong. Trace each wrong fact to a source.

The last step produces a list of upstream errors, and most will be dull ones: an old address on a directory, a mismatched branch name, a doctor still listed at a branch they left.

Failure modes to expect

• Duplicate nodes. The same hospital marked up as two different @id values on different templates. Fix by centralising the @id generation.
• Department as a hospital. A department modelled as an independent Hospital, which implies a separate address and legal body. Use the department relationship under the branch.
• Orphan doctors. A doctor page with no hospitalAffiliation, or one that points to a retired branch.
• Claims in markup not visible on page. Accreditations or awards in JSON-LD that the page does not state.
• Over-linking. Dozens of sameAs URLs to low-quality directories dilute the signal. Keep the list short and authoritative.

Governance

Name an owner for the register, a technical owner for the templates and a compliance owner for public claims. For hospitals in India, public statements about doctors and services must also fit NMC advertising rules and your accreditation obligations. Link the register change log to your content review workflow so that a new doctor, department or branch cannot go live in markup before the facts are approved.

Where to start

• Build the entity register for the group, branches and departments first. Add doctors in phases.
• Define the @id pattern and implement it in one template, such as the branch page.
• Search Wikidata for existing items before creating anything.
• Run the consistency audit on one branch, fix what it finds and then roll out.
• Keep the audit log; you will need it when a rebrand arrives.

If your team wants help organising citations and publication workflows that support visibility across AI search, AiLLMz is built for that. Our medical entity SEO service and schema markup service cover the implementation, and the multi-location healthcare SEO guide covers the branch-level marketing around it.