Describes, does not replace
OURS is not a new schema and not a competitor to the standards you already publish against. It is a way to say which ones you use and how.
The Open Unified Resource Standard
Publish a machine-readable map of what your data means and how it relates to the standards you already use, so another system can integrate without asking you first.
Most integration problems do not come from missing standards. They come from missing explanations of how those standards are used together. Today those explanations live in documentation, in code, and in people’s heads. OURS turns them into a handful of JSON files that a system can fetch and act on.
Start from a domain
Section titled “Start from a domain”A consumer needs to be given your domain and nothing else. The ontology sits at a well-known URI, where anyone can find it without being told where to look.
curl https://example.org/.well-known/ours.json{"resourceType": "Ontology","id": "example-org","url": "https://ours.example.org/ontology.json","version": "1.0.0","publisher": "ExampleOrg","models": "https://ours.example.org/models.json","vocabularies": "https://ours.example.org/vocabularies.json","mappings": "https://ours.example.org/mappings.json"}That file says where the models, vocabularies and mappings live. Everything else a consumer does is fetching from those three addresses.
Built on FHIR conventions
Resources follow FHIR’s shape, and the executable mappings are FHIR StructureMaps and ConceptMaps, so existing FHIR tooling can process them. Nothing about the format is specific to healthcare.
No prior coordination
Publish at the well-known URI and a consumer can discover the whole ontology on their own. There is no registry to join and no handshake to arrange.
Ordinary JSON Schema underneath
Models point at JSON Schema, and every vocabulary is also served as a schema, so an off-the-shelf validator enforces your codes without knowing what OURS is.
We’re looking to build the glue that connects standards together.
Adopting OURS asks you to change no data, no schema and no API. What it adds is the correspondence between the standards you already use, and that part has never had a home. It gets written into an adapter, or a PDF, or a thread nobody can find, once per integration, by whoever is doing that integration. OURS is a place to put it where the next person does not have to ask.
Read and validate it in TypeScript
Section titled “Read and validate it in TypeScript”@openhi/ours parses the resources, assembles an ontology from
documents however you obtained them, and runs the cross-resource checks a
publisher should pass before publishing.
npm install @openhi/oursAn ontology is also close to what an agent needs to transform data between two systems without guessing at the correspondences.