MedMij:V2018.06 Qualification
{{#customtitle:MedMij Qualification|MedMij Qualification}}
|
|
This is a draft page. The published version can be found here: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2018.06_Qualification |
Introduction
General
Scope
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 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.
Fixed tokens in use
The following source provides a list of tokens and patients that shall be used: Qualification Tokens