## 4 Model Proposal
### The Model Proposal: A Prototype for Managing Medication Prescriptions  
In the following section, a prototype of the proposal, related to the creation and exchange of the medication prescriptions as VCs, is described in detail. In this scenario, the list of medicines prescribed can be bought in any pharmacy provided that the pharmacist is able to verify the holder's, as well as the issuer's, proofs, and hence the prescription itself.  
The credential schema proposed for medication prescription is that shown in Listing 1. The credentials' schemas are stored on the IPFS to support the credential verification process.  
When a patient/holder presents a prescription to a pharmacist/verifier, the latter will have all the information that allows them to verify the validity of the prescription presented to them.  
The functional requirements that the prototype has to achieve are defined through the following user stories, to which the first four user stories previously listed have to be added.  
* Medication prescriptions are issued by an issuer, the doctor, and delivered to the patient.
* The patient keeps the prescription and presents it to the pharmacist when purchasing the prescribed medicines.
* Before selling the prescribed items, the pharmacist has to ensure that the prescription is valid.
* Before selling prescribed items, the pharmacist has to ensure that the person buying the medicines is the one to whom the prescription was issued.
* A doctor asks the patient to see the list of prescribed medicines.  
Figure 5: DID document with added service endpoint.  
Figure 6 shows the UML diagram of the use cases, in which by the Veramo agent, the doctor, the patient, and the pharmacist are represented. The use cases shown in the figure represent the user stories described above.  
The smart contract, _CredentialIssuerRegistry_, in this prototype is re-named _PrescriptionIssuerRegistry_. Figure 7 shows its UML class diagram.  
The smart contract contains two _mappings_, _authorizedIssuerRegistry_ and _prescriptions_, a _struct_, two methods, and two _modifiers_. The _mapping authorizedIssuerRegistry_ stores the identification code of the authorized issuers, associating each code with a DID, and hence with an address. This mapping is populated using the _addAuthorizedIssuer_ method, whose calls are managed through the _onlyOwner modifier_, which allows only the contract owner to run the method just mentioned. In turn, in the _mapping prescriptions_, the authorized issuers can store the _struct_ named _prescription_, which contains two variables, the hash and the status of the issued credential. The first variable is of the type _bytes32_ and the second is of the type _string_. The mapping is populated using the _addPrescription_ method, whose calls are managed through the _onlyAuthorizedIssuers modifier_.  
As regards the creation of the verifiable prescription, the issuer, and hence the doctor, starts with the creation of a credential message following the prescription schema shown in Listing 1 and builds the VC with the proof as shown in Listing 2.  
Figure 6: Use case diagram.  
Figure 7: UML class diagram of the _CredentialIssuerRegistry.sol_ contract.  
Based on the very early research presented in this article, several avenues for future work emerge that could significantly enhance the applicability and robustness of our model proposal. First, a critical area for future investigation is the data storage mechanism, particularly concerning how digital wallets manage VCs. Another critical area is the integration of ZKPs, which represent a pivotal step in reinforcing the privacy and security of our proposal. ZKPs allow one party to prove to another that a statement is true without revealing any additional information beyond the validity of that statement. Finally, the comprehensive testing and evaluation of the proposed prototype, and of prototypes related to other use cases, is essential for validating the model proposal.