its-rest

name

its-rest

description

Create, edit, or review the openEHR ITS-REST API sources (OpenAPI 3.0 YAML + Markdown) in the `specifications-ITS-REST` repo. This skill should be used when the user asks to add or edit a REST endpoint/operation/schema/response, write an operation description, review the ITS-REST spec, or update its amendment record. Not for AsciiDoc specs (use authoring) — including the AsciiDoc docs under `specifications-ITS-REST/docs/` (simplified_formats, smart_app_launch).

openEHR ITS-REST API Specification Authoring

This skill covers creating and editing the openEHR REST API specification sources in the specifications-ITS-REST repository. Unlike other specifications-XX repos that use AsciiDoc, ITS-REST uses OpenAPI 3.0.3 YAML with Markdown descriptions, split across many small files that are bundled into publishable artifacts.

Exception: The docs/ directory contains some AsciiDoc-based specs (e.g., simplified_formats, smart_app_launch) that follow the standard openEHR authoring conventions. This skill does NOT cover those — use the authoring skill instead.

References

• File-format conventions: see references/file-formats.md for the detailed format and conventions of each source type — top-level entry YAML, operation files, schema files, Markdown description files, and the HTML amendment record. Load it when writing or editing any of these.
• Build toolchain: see references/build-pipeline.md for the full Redocly + PHP pipeline, validation, live preview, and code generation.

Repository Structure

specifications-ITS-REST/
├── specifications/                    # Source OpenAPI specs (authoring)
│   ├── overview.openapi.yaml          # Top-level entry: overview/cross-cutting concerns
│   ├── ehr.openapi.yaml               # Top-level entry: EHR API
│   ├── query.openapi.yaml             # Top-level entry: Query API
│   ├── definition.openapi.yaml        # Top-level entry: Definition API
│   ├── demographic.openapi.yaml       # Top-level entry: Demographic API
│   ├── system.openapi.yaml            # Top-level entry: System API
│   ├── admin.openapi.yaml             # Top-level entry: Admin API
│   ├── operations/                    # One YAML file per API operation
│   ├── schemas/<domain>/              # Reusable schema components (ehr, query, common, …)
│   ├── parameters/{path,query,header}/ # Reusable parameter definitions
│   ├── responses/                     # Reusable response definitions
│   ├── headers/                       # Reusable response header definitions
│   ├── docs/<domain>/                 # Markdown description files (overview, ehr, query, …)
│   └── tags/                          # Tag description files (schema docs)
├── computable/OAS/                    # Build output (bundled specs in JSON/YAML)
├── docs/                              # AsciiDoc specs AND rendered HTML output
│   ├── simplified_formats/            # AsciiDoc spec (use authoring skill)
│   ├── smart_app_launch/              # AsciiDoc spec (use authoring skill)
│   └── *.html                         # Rendered HTML (build output)
├── development/                       # Build tooling (PHP, Docker, Makefile)
├── manifest.json                      # Component manifest
├── Makefile                           # Top-level build targets
└── .redocly.yaml                      # Redocly configuration

Source File Types

Each source type has its own format and conventions — detailed in references/file-formats.md:

Source	Location	Holds
Top-level entry	specifications/<domain>.openapi.yaml	info/x-status/x-spec, servers, paths wiring operations via $ref
Operation	specifications/operations/<resource>_<action>.yaml	operationId, summary, tags, params, requestBody, responses (all $ref)
Schema	specifications/schemas/<domain>/<SchemaName>.yaml	PascalCase title = RM class name, properties, $refs
Markdown description	specifications/docs/<domain>/Description.md	RFC 2119 prose, hardcoded spec URLs, http/json code examples
Amendment record	specifications/docs/overview/Amendment_record.md	HTML table, SPECITS Jira links (not AsciiDoc)

Build Toolchain

Quick reference from the development/ directory (full details in references/build-pipeline.md):

make bundle SPEC=ehr        # Bundle a single spec
make validate SPEC=ehr      # Validate
make all                    # Bundle all specs

Adding a New Endpoint

1. Create the operation file: specifications/operations/<operation_id>.yaml
2. Add shared parameters to specifications/parameters/ if new ones are needed
3. Add shared response definitions to specifications/responses/ if new ones are needed
4. Add or reference schemas in specifications/schemas/<domain>/
5. Wire the operation into the appropriate top-level *.openapi.yaml under paths:
6. Update the amendment record in specifications/docs/overview/Amendment_record.md
7. Bundle and validate: cd development && make bundle SPEC=<spec> && make validate SPEC=<spec>

Adding a New Schema

1. Create specifications/schemas/<domain>/<SchemaName>.yaml
2. Reference it from the operation or parent schema via $ref
3. Use title matching the RM class name
4. Follow existing patterns for required, type, properties, and description

Scope Boundaries

• This skill covers the OpenAPI YAML and Markdown sources in specifications-ITS-REST/specifications/
• It does NOT cover AsciiDoc documents in specifications-ITS-REST/docs/ (simplified_formats, smart_app_launch) — use authoring for those
• It does NOT cover the PHP build tooling in development/ — consult .junie/guidelines.md for that
• It does NOT cover other specifications-XX repositories