What OURS is

OURS, pronounced like “ours”, is a shared format for describing which standards you use, how you use them, and how data moves between them. A publisher serves a few JSON files at stable URLs. A consumer fetches them and knows enough to integrate.

The problem it addresses

Standards are not usually the missing piece. FHIR exists. schema.org exists. ISO publishes code lists for most things worth coding. What is missing is the explanation of how a particular system uses them: which of its own types correspond to which standard types, which code lists it draws on, where its own vocabulary differs, and what is lost in the conversion.

That explanation exists in every integration. It is written in a PDF, or in the implementation of a one-off adapter, or in the head of the engineer who did the last one. None of those can be fetched, and none of them can be checked.

OURS makes that explanation a published artefact. Not prose about the mapping, but the mapping itself, in a form a program can read.

What it is not

OURS is not a new schema language and not a replacement for the standards you already publish against. It does not ask you to restructure your data or to adopt anyone’s model of the world. A publisher whose types are defined in FHIR StructureDefinitions keeps them. A publisher with a bespoke internal model keeps that too.

It is also not a registry. There is nothing to join and no central index to submit to. The ontology lives on your own domain, under your control, at a well-known URI that a consumer can reach without being told anything beyond the domain itself.

Its relationship to FHIR

OURS borrows FHIR’s conventions because they are good ones and because reusing them means existing tooling works. Every resource carries resourceType, id, url and version, and collections are FHIR Bundles. The executable mappings are FHIR StructureMaps and ConceptMaps, written in FHIR Mapping Language, so a FHIR mapping engine can run them unmodified.

None of this makes OURS a healthcare format. The shape was borrowed; the subject matter was not. An invoicing system, a logistics platform and a hospital can each publish an ontology, and each will look the same to a consumer.

Who each half is for

If you publish data, an ontology is how you stop answering the same integration questions one partner at a time. You describe your models once, say what they align to, and point at the transformations.

If you consume data, an ontology is what you fetch instead of reading a PDF. You learn what the publisher’s types mean, what they correspond to in a standard you already handle, and whether the correspondence is exact.

Next

How it works walks through the discovery pattern a consumer follows, from the one URL to the data.