FHIR Questionnaire 4.1 van Open Health Hub b.v. heeft standaardisatieniveau Volledig gestandaardiseerde API behaald. Dit betekent dat deze API voldoet aan tenminste alle 'moet'-eisen tot en met dit standaardisatieniveau.
Gepubliceerd
Deze API is gepubliceerd in de API-bibliotheek voor de Nederlandse gezondheidszorg
Open API
Open Health Hub b.v. verklaart dat deze API goed gedocumenteerd is en dat documentatie openbaar en vrij beschikbaar is
Technisch gestandaardiseerde API
Open Health Hub b.v. verklaart dat alle technische keuzes voor deze API voldoen aan internationaal erkende normen, richtlijnen en best practices
Volledig gestandaardiseerde API
Open Health Hub b.v. verklaart dat alle onderdelen van deze API zijn gestandaardiseerd en dat dit is gevalideerd tijdens een formeel test- of kwalificatieproces
Eisen
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 van Open Health Hub b.v. heeft standaardisatieniveau Volledig gestandaardiseerde API behaald. Dit betekent dat deze API voldoet aan tenminste alle 'moet'-eisen tot en met dit standaardisatieniveau.
Gepubliceerd
Deze API is gepubliceerd in de API-bibliotheek voor de Nederlandse gezondheidszorg
Open Health Hub b.v. verklaart dat alle onderdelen van deze API zijn gestandaardiseerd en dat dit is gevalideerd tijdens een formeel test- of kwalificatieproces
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.