# SCoPE: Service Composition and Personalization Environment
## 5 ECE Environment
### Step: 1--Scope Filtering  
This step is responsible for the matching of [service, provider] pairs that can meet the customer's request. The process is based on goals of the taxonomy of care needs and customer's requirements. First, the {service, provider} pairs are selected based on \(TX^{\prime}\) goals (with penalties for pairs that do not meet the same level of selected \(TX^{\prime}\) goal). In the second stage, these pairs are filtered based on _hard_ constraints (customer's requirements' type restriction hard, customer's limitations, service application restrictions, etc.).  
For instance, if service delivery is not guaranteed in the customer's region, it is excluded, or if the service requires a specific resource which the customer does not have, this service is excluded. These are just some examples of hard restrictions for the exclusion process, but others can be considered, e.g., maximum cost, service provider preference, delivery time, etc.  
At the end, a suitable set of \(sp_{ij}\) for the customer (and related care needs) is identified. Algorithm 1 shows a partial and simplified pseudo code formalism of _Scope Filtering_.  
Figure 5: Steps in service selection and composition.  
```
functionScopeFiltering; //ECE is the ecosystem, cu is the customer, CA' the set of relevant care needs to be processed Input:ECE,cu,CA' //SSE is a set of tuples, in which cu is the customer, ca is a care need of the customer cu, se is the service that can attend the care need, and weight is the matching level of the service associated with the service taxonomy Output:SSE=|<cu,ca,se,weight>| //Variables varLSE;//a set containing services (SE) varLweight;//a weight to associate with the taxonomy matching varPenalty:0.1;//Penalty for higher-level matching //Main foreachan inCA'do \(\text{LSE}\leftarrow\text{null}\); foreachspinECE.SPdo foreachseinsp.SEdo //provided services (SE) by specific service provider(sp) \(\text{\emph{Lweight}}\gets 1\); \(\text{\emph{More}}\leftarrow\text{\emph{true}}\); \(\text{\emph{Node1}}\leftarrow\text{\emph{ca.taxonomy.node}}\); \(\text{\emph{Node2}}\leftarrow\text{\emph{searchNodeTaxonomy(se.taxonomy.node)}}\); whileTruedo if(Node2=null) or(Node1=Node2)then break; end else \(\text{\emph{Lweight}}\leftarrow\text{\emph{Lweight}}-\text{\emph{Penalty}}\); \(\text{\emph{Node2}}\leftarrow\text{\emph{Node2.parent}}\); end end if if(Lweight<=0) or(Node2=null)then //Did not have correspondence in the taxonomy \(\text{\emph{Lweight}}\gets 0\); \(\text{\emph{SSE}}\leftarrow\text{\emph{<cu,ca,se,Lweight>}}\); end end end end
```  
**Algorithm 1**Scope Filtering Algorithm  
Figure 6 illustrates the scenario previously presented for Mr. [PERSON]. The main care needs of Mr. [PERSON] are _haveSafety_ (associated with the node _Safety_) and _bloodPressure_ (associated with _diseaseMaintenance_). In this example, the identified services can be provided by either a unique service provider, or a VO. These aspects influence the adherence calculation of the suggested _spij_ fragments.  
Let us imagine that based on the matching of care needs and services, the following services are found: \(s_{1}\): _Security_Guard Service_; \(s_{2}\): _Remote_Monitoring Service_; \(s_{3}\): _Agenda_Reminder Service_; \(s_{4}\): _Medication_Alert Service_; \(s_{5}\): _Nursing_Robotic_; and \(s_{6}\): _Home_Exercise Service_. However, considering that \(s_{5}\) (_Nursing_Robotic_) is not recommended for diabetic patients, which is the case of Mr. [PERSON], \(s_{5}\) is removed from the list.