Test results

An overview of all test results for Verzamelen Huisartsgegevens 2.0 from Nictiz.

Add test results

API details

Verzamelen Huisartsgegevens

2.0

Test details

API requirements 1.2.0

August 28, 2024

Nictiz

Nictiz is de Nederlandse kennisorganisatie voor digitale informatievoorziening in de zorg.

Verzamelen Huisartsgegevens 2.0

Het verzamelen van huisartsgegevens: je medische dossier bij je huisarts.

Den Haag, The Netherlands

https://nictiz.nl/

Verzamelen Huisartsgegevens 2.0 from Nictiz 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

Nictiz declares that this API is well-documented and that the documentation is publicly and freely available

Technically standardized API

Nictiz declares that all technical choices for this API comply with internationally recognized standards, guidelines, and best practices

Fully standardized API

Nictiz 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

SD001: API documentation MUST be publicly and freely available

View documentation

SD001.001: API specification MUST contain enough information for a competent developer to create an API implementation or an API client without further information

View documentation

SD001.002: API specification MAY refer to other specifications to cover elements

View documentation

SD001.003: API specification MUST cover identification and authentication of people, organizations, and machines

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.

View documentation

SD001.004: API specification MUST cover authorization/access control

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.

View documentation

SD001.005: API specification MUST cover protecting integrity and confidentiality

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.

View documentation

SD001.006: API specification MUST cover addressing

This applies to specifics on addressing API endpoints and mechanisms used to distribute (updates to) addresses.

View documentation

SD001.007: API specification MUST cover content encoding

This applies to specifics on content encoding such as the compression algorithms used and character encoding.

View documentation

SD001.008: API specification MUST cover content formatting

Specifics on content formatting such as the use of MTOM/XOP and BSON but also healthcare-specific (data) formats.

View documentation

SD001.009: API specification MUST cover exchange patterns and exchange paradigms used

View documentation

SD001.010: API specification MUST cover API signature and semantics

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.

View documentation

SD001.011: API specification MUST cover use cases

How to (and how not to) use the API in specific use cases.

View documentation

SD001.012: API specification MUST cover references to other specifications

Most specifications reuse other specifications such as RFCs created by IETF or W3C or Dutch information standards created by Nictiz.

View documentation

SD001.013: API documentation MUST be freely available and accessible via a public website

View documentation

SD001.014: API documentation MAY refer to paid content published by standardization organizations

View documentation

SD001.015: Access to API documentation MAY require free registration

View documentation

SD001.016: API documentation MAY be copyright protected

View documentation

SD001.017: Distribution of API documentation without explicit permission of the API specifier MAY be restricted

View documentation

SD002: API documentation MUST provide examples of how to use the API

View documentation

SD002.001: API documentation MUST include examples for the most common use cases

View documentation

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

View documentation

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

View documentation

SD003: API documentation SHOULD provide examples of input and output data

View documentation

SD003.001: Documentation for all API methods SHOULD contain examples of input and output data, using a supported data format such as JSON or XML

View documentation

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

View documentation

SD004: API documentation SHOULD include a FAQ page for API client developers

View documentation

SD004.001: A FAQ SHOULD be made available for developers that want to use the API(s)

View documentation

SD004.002: The FAQ SHOULD be written in an actual question-and-answer format

View documentation

SD004.003: Questions and answers SHOULD be written from the point of view of the API client developer

View documentation

SD004.004: Questions SHOULD include the most common problems and misconceptions that API client developers run into when using the API

View documentation

SD005: API documentation MAY specify cases in which API usage is not applicable

View documentation

SD005.001: API documentation MAY include cases in which API usage is not applicable or not supported

View documentation

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

View documentation

SD009: API documentation SHOULD be published in English

View documentation

SD009.001: API documentation SHOULD be available in English

View documentation

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

View documentation

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

View documentation

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

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).

View documentation

SD011: Content relationship MUST be described in API documentation

Some content cannot exist without its parent content. The API documentation must describe in which way the relationship is managed and used.

View documentation

SD012: API documentation MUST describe the availability and usage of operations

API operations can be extremely useful in specific use cases, describing the operations will make them even more useful.

View documentation

SD013: API versioning policy MUST be documented

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.

View documentation

SD014: API specifications MUST cover the rationale behind the exchange paradigm used by the API

Such as described in Exchange paradigms.

View documentation

DI001: API specifications SHOULD be published in the Dutch API library for healthcare

View documentation

DI001.001: The API specifier MUST specify the status of each version of its API specification published in the Dutch API library for healthcare

View documentation

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

View documentation

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

View documentation

LM001: API specifications MUST be marked deprecated when they are no longer recommended for use

View documentation

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

Specifications marked as deprecated are still supported but support may end soon.

View documentation

LM001.002: An API specifier MUST mark an API specification as deprecated for a period of at least one year, before it MAY be marked retired

View documentation

LM001.003: API server developers SHOULD replace the use of deprecated API specifications with newer versions or alternative API specifications

View documentation

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

View documentation

LM002: API specifications MUST be marked retired when they are no longer supported

View documentation

LM002.001: An API specifier MUST mark an API specification as retired (in the Dutch API library for healthcare) when it is no longer supported

View documentation

LM002.002: API server developers MUST replace the use of retired API specifications with newer versions or alternative API specifications

View documentation

LM002.003: API server developers MUST mark API implementations as retired when they are based on a retired API specification

View documentation

LM008: An API specification MUST comply with Semantic Versioning specification (SemVer) version 2.0.0

View documentation

DR001: Interfaces MUST be defined in English

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.

View documentation

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

This way, the receiving party can decide when or how the transferred data is received and processed.

View documentation

DR-R001: APIs MUST use nouns to name resources

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.

View documentation

DR-R002: APIs MUST consistently use either singular nouns or plural nouns to name collection resources

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).

View documentation

SC001: API specifications MUST comply with Dutch NCSC guidelines for web applications

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.

View documentation

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

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.

View documentation

SC007: APIs MUST use fully standardized models for identification and authentication

View documentation

SC008: All tokens used for client authentication MUST be signed using asymmetrical encryption

View documentation

SC009: When generic services/functions are nationally prescribed for use, APIs MUST use these generic services/functions

For example, Patient Consent, Addressing, Authorization models.

View documentation

SC-R001: APIs MUST comply with RFC 7523 or its successor for client authentication and for requesting OAuth 2 access tokens

RFC 7523 describes the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants.

View documentation

SC-R002: APIs SHOULD use OpenID Connect to achieve Single-Sign-On when requesting OAuth access tokens

As far as existing regulations allow.

View documentation

SC-R003: JWT tokens used for client authentication and authorization grants MUST comply with RFC 7515 and RFC 7518, or its successors

RFC 7515 describes the JSON Web Signature (JWS), a data structure representing a digitally signed or MACed (Message Authentication Codes) message.

RFC 7518 describes the JSON Web Algorithms (JWA).

View documentation

IS001: In order to be fully standardized, an API specification MUST be approved by an authoritative body

View documentation

IS003: All API input and output data SHOULD comply with ZIB specifications

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.

View documentation

IS003.001: API input data, such as parameters and post data, SHOULD comply with ZIB specifications where applicable

Applicable refers to input or output data that represents general health and care concepts.

View documentation

IS003.002: API output data, such as resources, documents or procedure results SHOULD comply with ZIB specifications where applicable

View documentation