Toetsresultaten

Een overzicht van alle toetsresultaten voor Verzamelen Huisartsgegevens 2.0 van Nictiz.

Nieuwe toetsresultaten

API-gegevens

Nictiz

Verzamelen Huisartsgegevens

2.0

Toetsgegevens

API-eisen 1.2.0

28 augustus 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, Nederland

https://nictiz.nl/

info@nictiz.nl

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

53 voldoen

Nictiz verklaart dat deze API goed gedocumenteerd is en dat documentatie openbaar en vrij beschikbaar is

Technisch gestandaardiseerde API

13 voldoen

Nictiz verklaart dat alle technische keuzes voor deze API voldoen aan internationaal erkende normen, richtlijnen en best practices

Volledig gestandaardiseerde API

6 voldoen

Nictiz verklaart dat alle onderdelen van deze API zijn gestandaardiseerd en dat dit is gevalideerd tijdens een formeel test- of kwalificatieproces

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, Nederland

https://nictiz.nl/

info@nictiz.nl

Gepubliceerd

Deze API is gepubliceerd in de API-bibliotheek voor de Nederlandse gezondheidszorg

Open API

Nictiz verklaart dat deze API goed gedocumenteerd is en dat documentatie openbaar en vrij beschikbaar is

Technisch gestandaardiseerde API

Nictiz verklaart dat alle technische keuzes voor deze API voldoen aan internationaal erkende normen, richtlijnen en best practices

Volledig gestandaardiseerde API

Nictiz verklaart dat alle onderdelen van deze API zijn gestandaardiseerd en dat dit is gevalideerd tijdens een formeel test- of kwalificatieproces

Eisen

72 items

items

SD001: API documentation MUST be publicly and freely available

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

SD001.006: API specification MUST cover addressing

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

Bekijk documentatie

SD001.007: API specification MUST cover content encoding

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

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

SD001.011: API specification MUST cover use cases

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

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

SD001.016: API documentation MAY be copyright protected

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

SD009: API documentation SHOULD be published in English

Bekijk documentatie

SD009.001: API documentation SHOULD be available in English

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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

Such as described in Exchange paradigms.

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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

For example, Patient Consent, Addressing, Authorization models.

Bekijk documentatie

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.

Bekijk documentatie

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

As far as existing regulations allow.

Bekijk documentatie

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

Bekijk documentatie

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

Bekijk documentatie

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.

Bekijk documentatie

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.

Bekijk documentatie

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

Bekijk documentatie