Merge pull request #104 from IKNL/task-55-and-101-add-wording-on-addressing-and-patient-context

#55 Clarify API scope and #101 patient context

Author: ArdonToonstra

input/pagecontent/data-exchange.md

@@ -21,11 +21,13 @@ The ACP Actor Provider SHALL support at least one of the four transaction groups
 
 ### General API requirements
 
-All interactions adhere to the following principles.
+This IG focuses solely on defining how ACP health information is accessed and structured for data exchange. It does not specify supporting functionalities such as addressing, routing, localization, consent management, or authentication. These capabilities are expected to be provided by the underlying infrastructure specifications and agreements in use, such as Generic Functions, LSP, Twiin, or Nuts.
 
-1. **Authorization**: Accessing ACP information is subject to strict privacy and security rules. All API requests MUST be properly authenticated and authorized. The client application is expected to use a secure mechanism to obtain an access token with the necessary scopes to read the patient's clinical data. The exact methods may be found in the used infrastructure specification and agreements of e.g. LSP, Twiin and or Nuts.
-2. **Patient Context**: All queries described in this guide are patient-specific. The client MUST know the logical ID of the patient in question and include it in every query (e.g., `patient=123` or `subject=Patient/123`). This may require an initial request on the Patient endpoint with a search using a patient identifier like the BSN. This may also be described by other technical agreements.
-3. **Resolving references**: The returned resources may contain nested resources or references to other resources (like `Practitioner` or `RelatedPerson`). The client application may need to perform subsequent requests to resolve these references and display the full details.
+Within this scope, the following requirements apply:
+
+1. **Authorization**: Accessing ACP information is subject to strict privacy and security rules. All API requests MUST be properly authenticated and authorized. The client application is expected to use a secure mechanism to obtain an access token with the necessary scopes to read the patient's clinical data.
+2. **Patient Context**: All queries described in this guide are patient-specific. The client needs to know the logical ID of the patient and include it in every query (e.g., `patient=123` or `subject=Patient/123`). The method for obtaining the patient's logical ID is not specified in this IG, but may include: an initial search request on the Patient endpoint using a patient identifier such as the BSN; interactions as defined in [IHE PDQm ITI-119](https://profiles.ihe.net/ITI/PDQm/3.2.0/ITI-119.html); or any other method provided by the infrastructure.
+3. **Resolving References**: The returned resources may contain nested resources or references to other resources (such as `Practitioner` or `RelatedPerson`). The client application may need to perform subsequent requests to resolve these references and display the full details.
 
 ---