FHIR Questionnaire 4.1 from Open Health Hub b.v. has achieved standardization level Fully standardized API. This means that this API meets at least all 'must' requirements up to and including this standardization level.
Published
This API has been published in the API Library for Dutch Healthcare
Open API
Open Health Hub b.v. declares that this API is well-documented and that the documentation is publicly and freely available
Technically standardized API
Open Health Hub b.v. declares that all technical choices for this API comply with internationally recognized standards, guidelines, and best practices
Fully standardized API
Open Health Hub b.v. declares that all components of this API have been standardized and that this has been validated through a formal testing or qualification process
Requirements
items
72 items
SD001: API documentation MUST be publicly and freely available
All information is available at //developer.openhealthhub.com/#questionnaire
SD001.001: API specification MUST contain enough information for a competent developer to create an API implementation or an API client without further information
SD002.002: API documentation MUST clearly express the value of the API (for API client developers and API users) within the context of the most common use cases
SD005.002: When cases exist in which API usage is not applicable or not supported, API documentation MUST clearly state whether using the API in this way violates the API license agreement
SD009.002: If API documentation is available in English, typical Dutch terminology and names of people and organizations MUST be written down in their original Dutch form
SD009.003: If API documentation is available in English, domain concepts MUST be translated to their corresponding official English terms instead of using literal (word-for-word) translations
SD010: When documentation claims compliance to standards, specifications, guidelines and practices, policies or law, documentation MUST provide (references to) evidence to back up these claims
DI001.002: The API specifier MUST provide (a link to) all specification, documentation and qualification documents available for each version of its API specification published in the Dutch API library for healthcare
DI001.003: API specifications that are published in the Dutch API library for healthcare MUST at least comply with all requirements for Open APIs (Open API standardization level) that apply to the API specifier role
LM001.001: An API specifier MUST mark an API specification as deprecated (in the Dutch API library for healthcare) when it is no longer recommended for use
LM001.004: API server developers MUST mark API implementations as deprecated (in the Dutch API library for healthcare) when they are based on a deprecated API specification
DR012: When describing an API where data is being transferred to another party, the NOTIFIED PULL exchange pattern SHOULD be used rather than the PUSH exchange pattern
SC006: Specifications for 'System APIs' MUST use authentication and authorization models that are not specific to a use case or (type of) client or user
FHIR Questionnaire 4.1 from Open Health Hub b.v. has achieved standardization level Fully standardized API. This means that this API meets at least all 'must' requirements up to and including this standardization level.
Published
This API has been published in the API Library for Dutch Healthcare
Open Health Hub b.v. declares that all components of this API have been standardized and that this has been validated through a formal testing or qualification process
This does not only apply to the technical standards and specifics used to authenticate entities but also to the identifying attributes that are used and how to obtain and secure them to create a network of trust.
This does not only apply to the technical standards and specifics used to authorize access to APIs, but also to the semantics of access tokens and requests for access tokens, such as the permitted values for permissions (OAuth2 scopes) and expiration requirements.
This applies to any specifics on protecting integrity and confidentiality at both transport and message levels, including specifics on the cryptographic algorithms, key distribution and PKIs used.
This applies to specifics on addressing API endpoints and mechanisms used to distribute (updates to) addresses.
This applies to specifics on content encoding such as the compression algorithms used and character encoding.
Specifics on content formatting such as the use of MTOM/XOP and BSON but also healthcare-specific (data) formats.
All actions (methods) that are available through the API MUST be covered, as well as the legitimate data structures return (error) codes (the API signature), Including a full specification of all API requests and responses.
How to (and how not to) use the API in specific use cases.
Most specifications reuse other specifications such as RFCs created by IETF or W3C or Dutch information standards created by Nictiz.
Examples of evidence include official compliance certificates and statements (such as IHE integration statements and Nictiz qualifications) and independent auditor reports (such as security audit reports).
Some content cannot exist without its parent content. The API documentation must describe in which way the relationship is managed and used.
API operations can be extremely useful in specific use cases, describing the operations will make them even more useful.
The versioning of APIs and its policy must be documented in a clear manner. Use of versioning makes developing and debugging by API client developers easier.
Specifications marked as deprecated are still supported but support may end soon.
Healthcare APIs are used internationally, which is why a lot are already available in English. Conforming to this will help with uniformity and attract non-Dutch developers.
This way, the receiving party can decide when or how the transferred data is received and processed.
Because resources describe things (and thus not actions), resources are referred to using nouns (instead of verbs) that are relevant from the perspective of the user of the API.
Resources can be grouped into collections, which are resources in their own right and can typically be paged, sorted and filtered. Most often all collection members have the same type, but this is not necessarily the case. A resource describing multiple things is called a collection resource. Collection resources typically contain references to the underlying singular resources. The path segment describing the name of the collection resource MUST be written using a noun (thing) instead of a verb (action).
The Dutch governmental organization NCSC (National Cyber Security Centre) has specified IT Security Guidelines for Web Applications (Dutch). The API specifications MUST comply with these guidelines.
Compliance check will be limited to a confirmation by the specifier.
To ensure the disconnection between System APIs and other types of APIs, the authentication and authorization models used by System APIs cannot be specific to a use case or (type of) client or user.
For example, Patient Consent, Addressing, Authorization models.
RFC 7523 describes the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants.
As far as existing regulations allow.
RFC 7515 describes the JSON Web Signature (JWS), a data structure representing a digitally signed or MACed (Message Authentication Codes) message.
If no ZIB specification is available that governs the contents of certain API input or output but the input or output data represents general health and care concept, the API specifier MAY submit a ZIB change request to the Nictiz ZIB centre.
Applicable refers to input or output data that represents general health and care concepts.