MedMij Qualification

Qualification and testing

Requirements for qualification and testing

Qualification testing at Nictiz has a focus on the FHIR API and content and tests this as realistically as possible, but without including the full stack of requirements from the MedMij Afsprakenstelsel. This separation of concern avoids duplicating efforts of qualification testing that specifically targets the full range of requirements from the MedMij Afsprakenstelsel, without compromising the goal of 'production like' testing.

In order to have a clear separation of concern and focus on the FHIR API and content we have two very notable issues that requires additional support from you as vendor for and those are vendor context and patient context.

vendor context

When we test your system, we need to know what system to associate results with. If your system is the server this is understood: we know what system we are communicating with. If your system is a client, this could be unclear as multiple systems could be behind the same originating IP address. When this is the case we need a USER_KEY (preferred) or ORG_KEY string in the request to distinguish systems. This key, as assigned by the qualification testing platform, is typically sent as http header in your request. For more information on how matching requests to tests works, please see the qualification/testing platform documentation.

patient context

The MedMij Afsprakenstelsel disallows use of the Dutch national patient identifier Burgerservicenummer in query parameters and content. The only supported method for requesting data for a particular patient is the OAuth token, sent from a FHIR client to a FHIR server. See MedMij Afsprakenstelsel for details. The way to get that token is through a process involving identification/authentication/authorization with DigiD and the healthcare provider. In order to have the aforementioned separation of concern and focus on the FHIR API and contents we will skip that part and work with fixed tokens. The fixed tokens shall conform to the same requirements as 'regular tokens'.

What do fixed tokens do

For any patient we test with, there is a fixed, non-expiring, fully authorized token. When you supply said token with your FHIR request, the server is expected to retrieve data for that particular fictitious patient.

What does this mean for you

Client-side

When you initiate a session with the qualification environment for the patient specified in the qualification scenario, you need to be able to skip the flow as defined in the Afsprakenstelsel for identification/authentication/authorization and supply the correct token string with your request to the FHIR server (OAuth resource server in Afsprakenstelsel terms). Note that nothing prohibits you from using the same mechanism with other parties you engage a test session with, e.g. in a connectathon setting.

Server-side

The server-side can be dealt with in two ways:

1. The server shall have a pre-configured registry of the fixed tokens so it knows which patient it should serve data from. When you receive a request with a token that matches one of the defined tokens, the server shall respond as if this was a regular authenticated patient. Note that nothing prohibits a server from including a configuration setting that prohibits access to these patients outside of specific test windows, or to limit use to specifically configured client domains.
2. The people operating the server may initiate the full process that the MedMij Afsprakenstelsel specifies, and then enter the resulting OAuth bearer token in the Touchstone environment as an override for the default value. After the Test Script is started, this token is used for all defined actions in the underlying Test Script. The string to enter takes the form of Bearer<space><token>, e.g. "Bearer 0aed465d-aab0-4417-9b3c-e6f635892fea" (without quotes). Entry field will be labeled "Token_<patient last name>", e.g.

Fixed tokens in use

The following source provides a list of tokens and patients that shall be used: Qualification Tokens