De eisen voor Application Programming Interfaces (API's) in de Nederlandse gezondheidszorg.
De Wegiz verplicht het gebruik en de publicatie van "Open API's".
Transparantie van documentatie, testbaarheid en onboarding-procedures.
Technische keuzes gericht op het vergroten van de harmonisatie van API's.
API's die zijn gevalideerd tijdens een formeel test- of kwalificatieproces.
items
236 items
SD001
API documentation MUST be publicly and freely available
SD001.001
API specification MUST contain enough information for a competent developer to create an API implementation or an API client without further information
SD001.002
API specification MAY refer to other specifications to cover elements
SD001.003
API specification MUST cover identification and authentication of people, organizations, and machines
SD001.004
API specification MUST cover authorization/access control
SD001.005
API specification MUST cover protecting integrity and confidentiality
SD001.008
API specification MUST cover content formatting
SD001.009
API specification MUST cover exchange patterns and exchange paradigms used
SD001.010
API specification MUST cover API signature and semantics
SD001.012
API specification MUST cover references to other specifications
SD001.013
API documentation MUST be freely available and accessible via a public website
SD001.014
API documentation MAY refer to paid content published by standardization organizations
SD001.015
Access to API documentation MAY require free registration
SD001.017
Distribution of API documentation without explicit permission of the API specifier MAY be restricted
SD002
API documentation MUST provide examples of how to use the API
SD002.001
API documentation MUST include examples for the most common use cases
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
SD002.003
When a use case involves integration of two or more APIs, API documentation MUST provide examples of how to use these APIs in collaboration
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.