Usage pattern

Here are a few examples of patterns of use that can give an idea of the possibilities that open up. Some of the examples will require functionality in addition to basic functionality, but they mainly provide a picture of what is possible when a distributed platform with authentication, authorization, anonymization via linked IDs and a personal Always available data warehouse.

Use against retailer

Customer goes to a retailer's website, the landing page loads and with it loads a client against the Haven (called Ward). The customer authenticates with Ward and a notification goes to the Retaileren with the message that Ward is authenticated, but no link exists between the customer's profile in the Haven and Retaileren. Norwegian who now has a cold start problem sends a request to obtain consent to connect the customer to the Retaileren, either by sending a customer number to the Haven gate or obtaining an ID from the Gate that the Retaileren itself stores with the customer number.  In addition, the Retaileren asks for a handful of consents to provide the customer with the best possible experience. If the customer responds Yes to the consents, he does not have to fill in anything about himself. Here it is up to the Retaileren to let the customer understand that they will the customer's best. The consents can withdraw or limit the customer via their profile in the Haven containing all the agrees the customer has entered into with services using Haven. This can either be to access to see what other stores the customer has data from or to query for data from a known service that normalizes data from different websites. An example could be from the opera that in addition to what performances the customer has been on has expanded the profile with data on why the customer is going to the opera. Whether the customer goes to the opera because the customer loves opera or whether it is because it is important to be perceived as intellectual will be able to be useful in terms of what experience is offered from the Retaileren.  Data from a service such as Spleis can possibly be used to see if the customer is a type that is keen to reduce the carbon footprint that will also be able to have something to say for which products are presented. It may be interesting to check which books the customer reads with data from ARK or another bookstore. You will also be able to check whether the customer has any interesting data from Amazon, Facebook or anyone who may have data that will be able to say anything about what products the customer has, is interested in or what kind of motivation it is that operates the customer.

Use against third-party services

Now that there exists a link to the customer, the Retaileren can ask the customer if this agrees to create links to external services. Let's assume that the Retaileren has an agreement with a reseller of programmatic marketing and a vendor of product recommendations. For the storage of data for product recommendations, more common consent is required, but this can be made easier for the customer to accept by the fact that neither the programmatic or recommendation provider has any opportunity to find out who the customer is and the customer has full opportunity to Even to delete the link without having to rely on the vendors paving themselves. This is done by loading the trackers of the vendors with an ID that is linked to the customer's profile but it is only Haven who knows which profile they are associated with. When the customer is the target in a betting round about the ad space won by the Retaileren and the ad load will programmatically send the vendor a request via Haven to the recommendation provider. Haven switches the ID of the customer in the dataset to the programmatic provider with the ID representing the customer at the recommendation vendor who can enrich the ad with recommendations based on the retailer's internal data. However, it is worth noting that some programmatic vendors are very reluctant to push an ID through their network. This may mean that they are uncertain about how the agencies will set themselves to this. Some smaller actors are positive and some larger ones have sent some mixed signals. This is an opportunity to cut out some links in programmatic marketing and at the same time make recommendations based on internal data.

Use in emergency medicine

A person gets an injury that causes him to go to the hospital. When the person arrives at the hospital, health care professionals try to get enough information to reasonably certainly be able to determine who the person is. For example, spoken name or phone number, physical identification or maybe even NFC or similar. Personnel in the hospital want to administer drugs but want to check whether the patient has a fitness level or uses drugs that cross-react. Based on the information about personals, a query is made against the profile of the medications one wants to use is OK. It is not necessary to access all data about the person as long as you are sufficiently sure that the answer is correct. If the patient uses natural medicine, this can also be in the profile. This also allows all actions relative to the patient to be automatically added to the person's profile. Though, if the patient's ID determination is too uncertain, the data between it must be stored until the patient's ID is secured. Anything that is recorded digitally in relation to the patient can also be stored in a blockchain to have a secure proof of what has been done. 

Use in a GP

The patient will arrive just fine, but seek medical advice and any further treatment. The GP wants to see what has happened and sends a samtykkeførespørsel to the patient – which the patient answers yes to. The GP has no need for either contacting the hospital or storing any of the patient's data in its own systems-beyond what is required by documentation. The GP requisicates a specialist for follow-up, prints out prescriptions and sends the necessary data to the NAV. Your GP does not need to collect data about work space, or contact information it is only necessary to obtain a consent from the patient to send out requests to the appropriate authorities. The requests will typically include what is requested and a new ID that is linked to the patient's profile. For even greater security, the requests can also be sent as temporary IDs that only authorized authorities can look up. 

Use at Hotel

A person comes into the lobby and has obviously had a tiring day. The person is on the way to an event in another city, but has due to delay lost further flight and will have to stay overnight at a hotel. The airline that tries to help has found a hotel with free rooms nearby and has asked the person for permission to send enough data to the hotel so that they can accept the person. The hotel does not obtain any relevant data about the person in its systems internally in addition to the request for free room, so the system decides to check with the user's HAVEN profile. Based on the data the hotel has already been given permission to use, an assessment of what other data it will be desirable to access is done. The system decides to request access to certain key data that it will use against a third-party service that generates psychological profiles. This costs something but if one can get the person not only to be well attended to but get a sense of being equal there is a good chance that the person will become a returning guest. The person who knows the HAVEN from the former knows that no information will get on the stray and that no other people will see the background of the choices the system makes. Based on available data, the system adds up to a small rest before a late dinner-where it is served something customized, exclusive and surprising-before it is added to an opportunity to meet a few other guests who are suitable for both moments and person. Any need for a refreshing night's sleep is arranged and the next morning the person leaves the hotel with the feeling of having been as well cared for as by her own mother but without unnecessary admonitions.