ワンクリックでManusで任意のスキルを実行

fhir-api

Expert guidance for implementing FHIR RESTful API servers and clients following the HL7 FHIR specification. Use this skill when implementing a FHIR server with REST endpoints, building a FHIR client, designing FHIR API routes and handlers, implementing FHIR operations (read, create, update, delete, search, history), working with FHIR bundles, batch requests, or transactions, handling FHIR content negotiation, headers, and versioning, or implementing conditional operations. Trigger keywords include "FHIR REST", "FHIR API", "FHIR server", "FHIR client", "FHIR endpoint", "FHIR operations", "RESTful FHIR", "implement FHIR".

Manusで実行

概要

インストールコマンド

npx skills add https://github.com/aehrc/pathling --skill fhir-api

このコマンドをClaude Codeにコピー＆ペーストしてスキルをインストール

ソース

aehrc/pathling

スター128

フォーク23

更新日2026年2月13日 01:17

ファイルエクスプローラー

4 ファイル

SKILL.md

readonly

name

fhir-api

description

FHIR REST API implementation

This skill provides guidance for implementing FHIR RESTful APIs according to the HL7 FHIR specification (R4/R5).

URL structure

All FHIR REST URLs follow the pattern:

[base]/[type]/[id]

[base]: Service base URL (e.g., https://fhir.example.org/r4)
[type]: Resource type (e.g., Patient, Observation)
[id]: Logical resource ID

URLs are case-sensitive and use UTF-8 encoding.

Core operations

Operation	HTTP	URL Pattern	Success
Read	GET	`[base]/[type]/[id]`	200
VRead	GET	`[base]/[type]/[id]/_history/[vid]`	200
Create	POST	`[base]/[type]`	201
Update	PUT	`[base]/[type]/[id]`	200/201
Patch	PATCH	`[base]/[type]/[id]`	200
Delete	DELETE	`[base]/[type]/[id]`	200/204
Search	GET/POST	`[base]/[type]?params`	200
History	GET	`[base]/[type]/[id]/_history`	200
Capabilities	GET	`[base]/metadata`	200
Batch/Transaction	POST	`[base]`	200

For detailed specifications of each operation, see references/operations.md.

Content negotiation

MIME types

Format	MIME Type
JSON	`application/fhir+json`
XML	`application/fhir+xml`
RDF	`application/fhir+turtle`

Use the Accept header for response format and Content-Type for request body format.

The _format query parameter overrides Accept when clients cannot set headers.

FHIR version

Specify version via MIME type parameter:

Accept: application/fhir+json; fhirVersion=4.0

Version mappings: 1.0 (R2), 3.0 (R3), 4.0 (R4), 4.3 (R4B), 5.0 (R5).

Required headers

Request headers

Header	Purpose	Example
Accept	Response format	`application/fhir+json`
Content-Type	Request body format	`application/fhir+json`
If-Match	Optimistic locking	`W/"123"`
If-None-Exist	Conditional create	`identifier=123`
Prefer	Return preference	`return=representation`

Response headers

Header	Purpose	Example
ETag	Version identifier	`W/"123"`
Location	New resource URL	`[base]/Patient/123/_history/1`
Last-Modified	Modification time	RFC 7231 date

Versioning and optimistic locking

FHIR uses weak ETags for version tracking:

Server returns ETag: W/"[versionId]" with responses
Client sends If-Match: W/"[versionId]" with updates
Server returns 412 Precondition Failed if version mismatch

Implement version-aware updates when CapabilityStatement.rest.resource.versioning is versioned-update.

Error handling

Return OperationOutcome resources for all errors:

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "invalid",
            "diagnostics": "Patient.birthDate: Invalid date format"
        }
    ]
}

Status codes

Code	Meaning
400	Invalid syntax or validation failure
404	Resource not found
409	Version conflict
410	Resource deleted
412	Precondition failed (version mismatch)
422	Business rule violation

Prefer header

Control response content with Prefer:

Value	Response body
`return=minimal`	Empty (headers only)
`return=representation`	Full resource
`return=OperationOutcome`	Validation outcome

For async operations, use Prefer: respond-async to get 202 Accepted with status polling URL.

Implementation checklist

Server implementations should:

Implement CapabilityStatement at /metadata
Support content negotiation (JSON at minimum)
Return proper ETags for versioned resources
Include Location header on create/update
Return OperationOutcome for all errors
Support _format parameter fallback
Honour Prefer header for response content

References

operations.md: Detailed operation specifications
search.md: Search parameter and result handling
batch-transaction.md: Batch and transaction processing

このリポジトリの他の Skills

同じリポジトリ

helm-charts

aehrc/pathling

Expert guidance for creating Helm charts with best practices. Use this skill when the user asks to create, modify, or review Helm charts, Kubernetes deployments, values.yaml files, or chart templates. Trigger keywords include "helm", "kubernetes chart", "k8s deployment", "helm template", "values.yaml".

2026-02-20128

playwright-testing

aehrc/pathling

Expert guidance for writing end-to-end tests with Playwright Test framework. Use this skill when writing browser automation tests, creating test suites, working with locators and assertions, mocking network requests, handling authentication, or configuring the Playwright test runner. Trigger keywords include "playwright", "e2e test", "end-to-end", "browser test", "getByRole", "locator", "toBeVisible", "page.goto", "test runner".

2026-02-20128

sonarcloud-api

aehrc/pathling

Expert guidance for using the SonarCloud API to interact with code quality analysis, projects, issues, quality gates, and metrics. Use this skill when making API calls to SonarCloud, automating code quality workflows, retrieving analysis results, managing projects programmatically, or integrating SonarCloud with CI/CD pipelines. Trigger keywords include "SonarCloud", "SonarCloud API", "code quality API", "SonarQube Cloud", "quality gate", "code analysis API", "SonarCloud measures", "SonarCloud issues".

2026-02-20128

wiremock

aehrc/pathling

Expert guidance for using WireMock in Java applications for HTTP API mocking and testing. Use this skill when the user asks to mock HTTP APIs, create API stubs, test REST clients, simulate network faults, verify HTTP requests, or integrate WireMock with Spring Boot. Trigger keywords include "wiremock", "mock http", "stub api", "http mock", "api testing", "rest mock", "simulate fault", "verify request", "spring boot wiremock".

2026-02-20128

databricks-cli

aehrc/pathling

Expert guidance for using the Databricks CLI to manage Databricks workspaces, clusters, jobs, pipelines, Unity Catalog, SQL warehouses, serving endpoints, secrets, bundles, and all other Databricks resources. Use this skill when running databricks commands, managing Databricks infrastructure, deploying bundles, querying serving endpoints, managing Unity Catalog objects, or automating Databricks workflows. Trigger keywords include "databricks", "databricks cli", "dbfs", "unity catalog", "databricks bundle", "databricks jobs", "databricks clusters", "sql warehouse", "serving endpoint", "databricks secrets".

2026-02-17128

hapi-fhir-server

aehrc/pathling

Expert guidance for implementing FHIR servers using HAPI FHIR Plain Server framework. Use this skill when creating RESTful FHIR server implementations, implementing resource providers, adding FHIR operations (read, create, update, delete, search, $operations), implementing server interceptors for logging, security, and validation, setting up authentication and authorisation, or configuring FHIR server behaviour. Trigger keywords include "HAPI", "FHIR server", "RestfulServer", "resource provider", "IResourceProvider", "FHIR interceptor", "AuthorizationInterceptor", "FhirContext", "FHIR validation", "FHIR search", "FHIR operation".

2026-02-13128

ソース

aehrc

aehrc/pathling

GitHub リポジトリを開く Creator のリポジトリを見る

インストールコマンド

ダウンロード

Manusで実行

役立つ用途SOC

ソフトウェア開発者コンピュータ・数学職15-1252L4

name

fhir-api

description

FHIR REST API implementation

This skill provides guidance for implementing FHIR RESTful APIs according to the HL7 FHIR specification (R4/R5).

URL structure

All FHIR REST URLs follow the pattern:

[base]/[type]/[id]

[base]: Service base URL (e.g., https://fhir.example.org/r4)
[type]: Resource type (e.g., Patient, Observation)
[id]: Logical resource ID

URLs are case-sensitive and use UTF-8 encoding.

Core operations

Operation	HTTP	URL Pattern	Success
Read	GET	`[base]/[type]/[id]`	200
VRead	GET	`[base]/[type]/[id]/_history/[vid]`	200
Create	POST	`[base]/[type]`	201
Update	PUT	`[base]/[type]/[id]`	200/201
Patch	PATCH	`[base]/[type]/[id]`	200
Delete	DELETE	`[base]/[type]/[id]`	200/204
Search	GET/POST	`[base]/[type]?params`	200
History	GET	`[base]/[type]/[id]/_history`	200
Capabilities	GET	`[base]/metadata`	200
Batch/Transaction	POST	`[base]`	200

For detailed specifications of each operation, see references/operations.md.

Content negotiation

MIME types

Format	MIME Type
JSON	`application/fhir+json`
XML	`application/fhir+xml`
RDF	`application/fhir+turtle`

Use the Accept header for response format and Content-Type for request body format.

The _format query parameter overrides Accept when clients cannot set headers.

FHIR version

Specify version via MIME type parameter:

Accept: application/fhir+json; fhirVersion=4.0

Version mappings: 1.0 (R2), 3.0 (R3), 4.0 (R4), 4.3 (R4B), 5.0 (R5).

Required headers

Request headers

Header	Purpose	Example
Accept	Response format	`application/fhir+json`
Content-Type	Request body format	`application/fhir+json`
If-Match	Optimistic locking	`W/"123"`
If-None-Exist	Conditional create	`identifier=123`
Prefer	Return preference	`return=representation`

Response headers

Header	Purpose	Example
ETag	Version identifier	`W/"123"`
Location	New resource URL	`[base]/Patient/123/_history/1`
Last-Modified	Modification time	RFC 7231 date

Versioning and optimistic locking

FHIR uses weak ETags for version tracking:

Server returns ETag: W/"[versionId]" with responses
Client sends If-Match: W/"[versionId]" with updates
Server returns 412 Precondition Failed if version mismatch

Implement version-aware updates when CapabilityStatement.rest.resource.versioning is versioned-update.

Error handling

Return OperationOutcome resources for all errors:

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "invalid",
            "diagnostics": "Patient.birthDate: Invalid date format"
        }
    ]
}

Status codes

Code	Meaning
400	Invalid syntax or validation failure
404	Resource not found
409	Version conflict
410	Resource deleted
412	Precondition failed (version mismatch)
422	Business rule violation

Prefer header

Control response content with Prefer:

Value	Response body
`return=minimal`	Empty (headers only)
`return=representation`	Full resource
`return=OperationOutcome`	Validation outcome

For async operations, use Prefer: respond-async to get 202 Accepted with status polling URL.

Implementation checklist

Server implementations should:

Implement CapabilityStatement at /metadata
Support content negotiation (JSON at minimum)
Return proper ETags for versioned resources
Include Location header on create/update
Return OperationOutcome for all errors
Support _format parameter fallback
Honour Prefer header for response content

References

operations.md: Detailed operation specifications
search.md: Search parameter and result handling
batch-transaction.md: Batch and transaction processing