Unattributed Code Systems

Copyright Fragment

This fragment is not visible to the reader

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

Type Reference Content
web www.gidsopenstandaarden.org IG © 2024+ gidsopenstandaarden . Package fhir.gidsopenstandaarden.welldata#0.1.0 based on FHIR 4.0.1 . Generated 2025-06-23
Links: Table of Contents | QA Report
web browser.ihtsdotools.org QuestionnaireAnswerCodes (a valid code from SNOMED CT )
http://hl7.org/fhir/ValueSet/questionnaire-answers
From the FHIR Standard
web mkjwk.org Gebruik bijv. mkjwk.org of een tool als jose om dit JSON formaat te genereren.
web www.oauth.com From the portal and module perspective, the middleware is integrated with an OAuth2 Authorization Code Flow .
web solidproject.org Authentication of the users in Welldata is based on the SOLID-OIDC specification. It defines how owners of the pods need to authenticate towards an IDP and how resource servers can verify the identity of pod owners based on that authentication. The SOLID-OIDC flow is described in detail here
web openid.net The SOLID-OIDC flow is based on the OIDC flow .
web docs.inrupt.com In order to access the resource in the pod, the client needs to exchange it's token for yet another token by calling the UMA service of Inrupt .
web github.com For launching between applications, the welldata project makes use of HTI 2.0. Please refer to the HTI 2.0 spec for details.
web openid.net The public key discovery must work with OpenID Connect Discovery 1.0 , in the sens that the aud and iss must be discoverable with .well-known/openid-configuration with a valid jwks_uri endpoint.
web wiki.ihe.net Atna standaard
web docs.inrupt.com An access request is a verifiable credentials where the request for access is captured of an application with a webId to a specific resource of a pod owner.
web docs.inrupt.com The call to create an access request is done by the application with the access token, it received from the We Are IDP, as Authorization: Bearer header, to the \issue endpoint of the Inrupt VC service .
web docs.kantarainitiative.org A resource can be fetched from the pod by providing an access token in the Authorization Bearer header. The client application has an access grant for access the resource. This access grant needs to be transformed in an access token. This is done via the UMA flow by calling the UMA service endpoint of Inrupt.
web docs.inrupt.com A resource can be fetched from the pod by providing an access token in the Authorization Bearer header. The client application has an access grant for access the resource. This access grant needs to be transformed in an access token. This is done via the UMA flow by calling the UMA service endpoint of Inrupt.
web nuts.nl The WellData project leverages the NUTS network as the foundation for trust management between all participants in the research data ecosystem. NUTS is an open-source trust network that facilitates secure data exchange in healthcare while maintaining user privacy and sovereignty.
web github.com In the We Are Demo backend application the client credentials flow is automatically executed and uses the following environment variables:
web openid.net The application should have endpoints according to the OpenID Connect Discovery 1.0 specification.
  • The /.well-known/openid-configuration` should have at least:
    • The issuer value matching the
    • The jwks_uri matching the JWKS endpoint.
  • The JWKS endpoint having the public key as JWK available by the JSON Web Key (JWK) specification .
    • Note that the kid value of the key will need to match the kid header of the signed JWT.
web en.wikipedia.org The timestamps follow the UNIX time convention, being the number of seconds since the epoch.
web github.com We already provided an implementation which make all the underlying steps transparant for the developer. This can be viewed in the We Are Demo Backend pod endpoints section.
web solidproject.org The OIDC/SOLID-OIDC specification defines how owners of the pods need to authenticate towards an IDP and how resource servers can verify the identity of pod owners based on that authentication. The SOLID-OIDC flow is described in detail here
web github.com Starting an authentication flow from the frontend application is explained in the Authentication part of the front end demo application, which can be found here .
web github.com This angular front end app will then redirect the user to login endpoint of the We Are Backend application . In order to successfully start the login flow, the right environment variables need to be set on the backend application:

Internal Images

anon-login-comp.png
anon-login-comp.png
anon-login-overview.png
anon-login-overview.png
anon-login-workflow.png
anon-login-workflow.png
tree-filter.png
tree-filter.png
welldata-overview.png
welldata-overview.png