The requirements for Application Programming Interfaces (APIs) in Dutch Healthcare.
The Wegiz mandates the use and publication of "Open APIs".
Transparency of documentation, testability and onboarding procedures.
Technical choices that aim to increase the harmonization of APIs.
APIs that have been verified during a formal test or qualification process.
items
35 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.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.006
API specification MUST cover addressing
SD001.007
API specification MUST cover content encoding
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
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
SD003.002
When the API server developer includes an SDK for easy access to the API, code samples MUST be provided for using the API through the SDK
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
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).