Brontekst bekijken van MedMij:V2019.01 Qualification

{{DISPLAYTITLE:MedMij Qualification|MedMij Qualification}}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch   
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]                
circle 1013 224 212 [[MedMij:V2019.01_Ontwerpen|Functioneel]]                
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]                
desc none                    
</imagemap>


=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 [https://touchstone.aegis.net/touchstone/userguide/html/client-testing/matching.html 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 [https://afsprakenstelsel.medmij.nl 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:
# 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.
# 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. [[Bestand:TouchstoneEnterToken.png|link=]]

===Fixed tokens in use===
The following source provides a list of tokens and patients that shall be used: [https://github.com/Nictiz/Nictiz-STU3-testscripts/blob/master/Configuration/QualificationTokens.json Qualification Tokens]