Our company DocCoin is working to create a 'DocCoin Telemedicine Ecosystem ", which makes telemedicine (in other words 'Internet medicine') even more accessible and convenient than now, including allowing the use of cryptocurrency tokens.

Our programmers and designers work on the remote telemedicine consultations software system on the basis of blockchain technology, as well as on the relevant smart contract, on sites and their interfaces, and our managers are engaged in marketing and presentations, persistently look for and find partners and negotiate with them.

Over the past two months, we have made great progress on our promising path.
We would like to talk about some of our achievements.

The list of items changed recently looks like this:
• site of the company,

• smart contract:
- technical requirements for it,
- implementation,
- alpha testing, API key test of the smart contract to the service,
- security audit,

• remote consultation system for telemedicine:
- technical task for the system,
- its correction and audit,
- architecture solution,
- WEB-design,
- software implementation of the system
• registration of participants,
• authorization,
• consultations,
• editing and deleting users profiles,
• arbitration,
• system control panel (back-office):
- authorization,
- statistics,
- connection with smart contract,
- directory;

• presentation and marketing.

Let's talk about this in more detail.

COMPANY WEBSITE

The design of the site of the company DocCoin (https://doc-coin.com/) was changed in such a way that it became even more pleasing to the eye, more convenient, more intuitive and friendly.

A famous poet N.A. Nekrasov once wrote:
"...words should be in crowded,
for thoughts there must be room ... "
But on our website both thoughts and words have room, so that our texts look beautiful and are easy to read.

The content of the DocCoin website has also been changed.
In the section "Our products" a page with explanations about the smart contract was added.

This page was added for the convenience of people who are not familiar very much with smart contracts, with cryptocurrencies and, in general, with blockchain technology.
Generally speaking, cryptocurrencies and smart contracts are something very important and promising, we call on everyone to pay close attention to them, because they will soon replace conventional currencies and legal contracts and thereby change the lives of all humanity. We urge you to prepare for the big changes in advance, so that they do not catch you unawares.

SMART CONTRACT

In the DocCoin Telemedicine Ecosystem, the Ethereum (ETH) blockchain smart contract is responsible for the security of transactions for DocCoin (DOC) cryptocurrency token payment and generally determines the algorithm (the process of the transactions) itself.

Smart Contract Technical Requirements

All the variables and 'objects' necessary for writing the algorithm are defined, as well as all methods and functions, even the possibility of resolving disputes on the transaction.
The algorithm of the smart contract is written.

Implementation of Smart Contract Algorithm

The algorithm has been converted into code.

Smart Contract Alpha Testing and Smart Contract API Keys to Service Testing

When testing API keys for the DocCoin service, a number of shortcomings were identified:
• a long response from the contract to the service;
• unstable operation of the service when connecting with cloud databases;
• all the consequences of the Internet connection termination were not taken into account;
• there are problems with configuring the interaction between the service control panel and the back-office through API keys.

All the shortcomings identified in the testing process were corrected by programmers, and re-testing showed that the fixes do not introduce new problems into the system.

We are pleased to state that the testing was successful, that our system is rapidly approaching the ideal.

Smart Contract Security Audit Made by the Help of a Third-Party Company

Audit is, in this case, a form of software (smart contract) reliability testing, and not a check of our accounting department. Audit is needed here to check whether hackers can hack us. As expected, they can not, according to an independent expert assessment.

The following shortcomings were identified (see below a quote from the audit report):

*1. Stylistics of the code. You need to decide on the style of writing. If the internal variables have the form with a bottom underscore at the beginning, then it is desirable to use this approach everywhere. However, in the code internal functions have underscores at the beginning, lower underscores at the end, and sometimes do not have it at all.

1. Contract DocCoin. If you position DocCoin as the ERC20 standard, it is desirable to initiate more functions from the standard. Of course, most likely it will be recognized as ERC20, but...

2. Of course, for mathematical calculations it is more appropriate to use safe libraries, but in your particular case they can be neglected. Because the actions are fixed. And if implemented, they will serve just for the beauty of the code and/or for helping paranoiacs sleep at night.

3. There is no fallback function. !!!Maybe!!! it should be added to the code.

The conclusion of the audit.

In terms of security there were no vulnerabilities found in the contract. Practically all of the comments are not critical.*

REMOTE (ONLINE) CONSULTATIONS SYSTEM

The system provides convenient means for information exchange between telemedicine consultants and their clients. Among other things, it introduces the possibility of remuneration for telemedicine services by means of DocCoin (DOC) token, which is an ERC20 token.

The security of these transactions is the responsibility of the smart contract in the Ethereum (ETH) blockchain.
For owners of the system and their representatives (arbitrators), a special management and monitoring system is provided, namely the 'DocCoin back office'.

Technical Specification, its Correction and Audit

The Technical specification had been prepared by a group of authors, then discussed in a wide range, then amended, then discussed again and so repeated until we achieved the desired result, and then this result has been audited.

Software Architecture Solution

We have adopted such an architectural solution that allows the designer to change the look of the site without affecting all programmers. With the chosen solution, specialists in narrow areas of programming and design solve their very important but narrow problems without interfering with each other. Professionals call it MVC pattern (Model-View-Controller).
Also, the system is built on the base of dividing into "frontend" and "backend", and this allows programmers, not just programmers and designers working almost independently of each other.
These software architecture solutions are made with taking into account the following main requirements for the system: simplicity, flexibility, reliability, and convenience for users.

When the work of the collective of people is divided into parts (into ‘modules’) so that one part (‘module’) does not influence or has little effect on the other, then each part of the general system can be changed and improved independently of the other, and this makes the system easily changeable (this is about ‘flexibility’).
Also, splitting a large task into several smaller ones ensures the simplicity of the system, since small ‘modules’ are simpler than large ones.
Reliability at work is ensured by simplicity, for the simple breaks less often.
Reliability during system improvements is provided by the system flexibility, or, in other words, the ability to quickly, even unnoticed by the user, replace any new broken ‘module’ with the old, tested ones.
Generally speaking, in the virtual programming world, the older the program, the more reliable it is, although in the real world of material objects, on the contrary, the older the car, for example, the more unreliable it is.
If we could do this, then if we did something and tested it, we would not change anything in the system... But this is impossible, unfortunately, because the world is constantly changing, and we adapt to it. For example, we constantly improve our services for the users based on their new wishes and after the appearance of new opportunities for service.

1. DocCoinDB (MSSQL 2016) – Database for DocCoin service.

2. FrontEndAPI. ASP NET Web service with Soap/JSON interface.
   In this API front end business logic is implemented.

3. BackEndAPI. ASP NET Web service with Soap/JSON interface.
   back office business logic is implemented.

4. FrontEnd web site (ASP NET MVC) – the main DocCoin project WEB site.

5. BackEnd web site (ASP NET MVC) – Control Panel of the service or back-office.

6. MobileAPI – API for mobile applications (release #2)

7. Mobile applications for IOS and Android.
   Mobile clients of the service with built-in DocCoin wallet. (release #2)

WEB- design

In WEB-design there is a lot of tricks. It is known, for example, that the eyes of people when viewing a picture behave roughly like when reading a book. People of the European and related culture first of all instinctively look at the same place they look when reading the book, namely, in the upper left corner of an image.
Therefore, when designing, it is necessary to put the most important part of the whole in this particular place (the upper left corner).
According to our opinion, we put there the most important thing, and this is the ‘emblem’ and ‘motto’ (‘logo’) of our DocCoin company. It will be convenient for those looking at our site, if we place in the most prominent place, attracting attention at the very first moment, a brief explanation in a few words and lines what is the essence of all our work.
Generally speaking, user-friendliness, including intuitive clarity and simplicity of design, is the first requirement for WEB design or, in other words, for the appearance of a site intended for users. This part of the system is the first priority for us, in this area designers dictate their will to programmers, and they strictly obey designers who are closest to the end users, the most important people in our system.

System Implementation

The system (its version 1.0) is ready for beta-testing by medical consultants and consists of the following components:

• User Registration (Client),
• User Registration (Consultant),
• Authorization (Clients & Consultants),
• Consultation (Client’s Side),
• Consultation (Consultant’s Side),
• User Profile Editing,
• User Profile Deleting,
• Arbitration,
• System Control Panel (Back-Office):
• Authorization,
• Statistics,
• Connection with Smart Contract
• Directories.

Let's talk about this in more detail.

User Registration (Client) Algorithm Implemented

1. The user visits the site.
2. The user selects the ‘Registration’ option.
3. The user selects ‘Client’ system role option.
4. The user enters a name, email, password, password confirmation, age, height, weight.
5. The user agrees with the terms of service by checking a box next to the link to the agreement conditions, when clicking on the link the text of the offer contract with the user appears in a new window.
6. The user receives to his or her e-mail the information specified by him or her during registration and, additionally, a link for activating the account together with instructions for creating the Ethereum wallet and Metamask plug-in installation.
7. After filling out the form and confirming the email address the user hits the page with the list of registered consultants with a search option with the possibility of filtering by specialty, the user status is set to "Waiting for the DocCoin Wallet Binding". A corresponding notification is set on the profile icon. In this status the user cannot use the services, and when selecting a consultant, a corresponding notification is displayed.
8. The user creates an Ethereum wallet (or uses previously created). Enter the profile and specify the wallet address in the corresponding field. After the form is closed its balance is displayed, the user status is changed to "Active", the user has the opportunity to receive a consultation.

User Registration (Consultant). Algorithm Implemented

1. The user visits the site.
2. The user selects the ‘Registration’ option.
3. The user selects ‘Consultant’ system role option.
4. The user enters his or her name, email, password, password confirmation, LinkedIn link, age, specialty, optionally writes additional information about himself or herself in the "Additional Information about You" field in order to increase the chances of choosing him or her for consultations by clients.
5. The user agrees with the terms of service by checking a box next to the link to the agreement conditions, and when clicking on the link the full text of the offer contract appears.
6. The user receives to his or her e-mail the information specified by him or her during registration and, additionally, a link for activating the account together with instructions for creating the Ethereum wallet.
7. The user registers the wallet and installs Metamask. The address of the wallet is registered in the profile.
8. The user after activation of the account and saving the address of the ETH wallet gets on the screen of incoming proposals. If the wallet is not specified, a corresponding notification is displayed in the profile. Without a wallet, the consultation is blocked.

Authorization. Algorithm Implemented

1. The user visits the site.
2. The user selects the ‘Authorization’ option.
3. The user enters e-mail and password specified during registration.
4. The user, depending on his or her role, hits the following page:
   • The consultant gets to the page with video chat ‘on hold’.
   • The client hits the page with the list of consultants registered in the system with the possibility of filtering by specialty.

Consultation (from the Side of Client). Implemented Algorithm

1. The user is authorized for the access to the system.
2. The user selects a physician for consultation. If the funds in the client's wallet are not sufficient for the services of this specialist, an appropriate error message is displayed.
3. The user makes payment for the service using the smart contract according to the tariff. The funds are transferred to the wallet of the smart contract.
4. The user receives a consultation.
5. The user, after receiving a report on the service provided, decides his problem
   is solved or not and presses the "End" button of the consultation, invoking the corresponding smart contract method and signing the Metamask request by the client. The funds from the DocCoin purse contract are transferred to the consultant minus the system commission.
6. The user receives information (on the e-mail he or she specified during registration) about when, at what time and who consulted him with the reference to the consultant.
7. The user enters the page with a list of consultants registered in the system with the possibility of searching with the possibility of filtering by specialty.
8. The user receives a report from the consultant about the most recent consultation (to the e-mail specified by him when registering) with a link to the page with buttons "Satisfied with Consultation" and "Arbitration". When you click on a link from the email, you are asked to confirm the transaction using the Metamask client. Funds are transferred to the account of the consultant. If the "Arbitration" button is pressed, the status of the transaction is changed to "The Arbitrator", and a form for filling in the claim for the service is opened, stored in the database. The arbitrator is informed of a new problem deal in the back office.

Consultation (from the Side of Consultant). Implemented Algorithm

1. The user is authorized for the access to the system.
2. The user enters the page of video chat in ‘on hold’ status;
3. When the client selects the user as a consultant, the user is notified by the system about changing the client's ‘on hold’ status to the status of ‘waiting for payment for the consultation’.
4. After the client pays for the consultation, the user is notified by the system about
   the beginning of the consultation. A video chat is started.
5. The user conducts a consultation.
6. The user decides that the client's issue is resolved and presses the "End Сonsultation" button.
7. The user receives information (on the email he or she specified during registration) about when, at what time and who consulted him with the reference to the consultant.
8. The user enters the page with a report form with the following fields:

• Reason for the Consultation;
• Possible Diseases;
• Recommendations for Prophylaxis.

1. The user sends the form, confirms the execution of the contract in the blockchain, invokes the corresponding method, signs the request to Metamask. The system automatically sends the form to the email specified by the client during registration, and also sends a duplicatition to the Consultant.
2. The user enters the page with video chat in ‘on hold’ status.

Editing the User Profile. Implemented Algorithm

1. The user is already logged in.
2. The user selects the ‘Edit Profile’ option.
3. The user hits the page with the fields filled in at registration.
4. The user changes the data at his discretion and presses the "Save" button
5. The user, depending on his or her role, hits the following page:
   • The consultant gets to the page with video chat ‘on hold’;
   • The client hits the page with the list of consultants registered in the system with the possibility of filtering by specialty

Deleting of User Profile. Implemented Algorithm

1. The user is already logged in.
2. The user selects the ‘Edit Profile’ option.
3. The user hits the page with the fields filled in at the time of registration.
4. The user selects the ‘Delete Profile’ option.
5. The user is asked to confirm or refuse to delete the Profile.
6. The user confirms deletion of the Profile.
7. The user is redirected to the page with an alert about the deleting of his data from the system with a link to the main page.
8. The user is notified about the removal of his data from the system at the email addresses he specified when registering.

Arbitration. Implemented Algorithm

From the Side of the Client

1. The client is dissatisfied with the consultation. Instead of the button "The Service is Rendered", the client presses the "Arbitration" button.
2. A form is displayed, where the client describes the claim.
3. The claim is retained in the system, the transaction in the smart contract is transferred to the "Arbitration" status. At the same time, the consultant is asked to fill out the form of a response to the claim for this transaction, the form contains the client's explanations.

From the Side of the Arbiter.

1. The arbitrator, who was automatically appointed by the system for this transaction, receives in the profile and on the email a notification about the receipt of the disputed transaction.
2. The arbitrator analyzes the client's claims and the explanations of the consultant and decides whether to return the funds to the client or transfer funds to the consultant.
3. The solution is recorded in the smart contract by calling the appropriate method.

**Note: **The system can be configured in such a way that all transactions after the description of claims to the consultant will be automatically resolved in favor of the client, but in the case of 3 consecutive transactions with a similar outcome, the user will be blocked by the system until the cause of the situation is clarified.

DocCoin Control Panel (DocCoin Back-Office)

1. Authorization
   The default SuperUser password is stored in the system. After authorization, it is possible to set a new SuperUser password and configure using 2 factor authentication via the Google Authenticator application.

2. Statistics panel.
   After authorization, for the user the ‘Statistics’ screen is displayed in which the following data from the DocCoin database is displayed.
   • Number of transactions on the project:
   Today, Total,% Growth/Fall to the Previous Day
   • The amount of transactions:
   Today, Total, % Growth.
   • The Amount of Service Revenue:
   Today, Total% growth.
   • Number of users in the system:
   Clients, Registered Today/Total, % Growth.
   • Number of users in the system:
   Consultants, registered Today/Total, % Growth.
   • Number of transactions involving an arbitrator:
   Today/Total, % Growth.
   • Service Attendance:
   Today, % Growth, Based on Authorization Data.

3. Smart Contract
   • Data are to be obtained from a smart contract through interaction with the local ETH node. All the contract variables and current transactions are to be shown for diagnosis purposes. A block is created for calling contract methods using Metamask with the owner keys.
   • Set or change account for commissions.
   • Add or remove an Arbitrator, arbitrator ID, address of his ETH wallet.
   • Set the commission fee in%.
   • Withdraw the commission from the commission account and send it to the specified address.
   • Remove from the array of closed transactions, forcibly.
   • View the balance amount of the contract wallet (for unclosed transactions).

4. Directories
   • Directory of All Users

By default the directory provides the list of all users with a role filter.

In this section, there is a possibility to allow access to the back-office of the system to a user assigning him or her the following roles:
- Administrator:
has read and edit access to all sections except the contract, can add Arbitrators, block, unlock consultants and clients.
**- Arbitrator: **
viewing disputed transactions, making decisions on the status of the transaction in a smart contract.
Super-Administrator can block any user in the system.
• Directory of Clients

Here you can sort Clients and search them by parameters.

Client Parameters:

• First Name, Last Name,
• E-mail,
• Date of Registration.

By default, Clients with the maximum registration date are displayed first.

After clicking on the user's card his or her full profile is displayed, there is a possibility to view comments from other users.

For the Administrator, Client lock/unlock icon is available.
• Directory of Consultants

Here you can sort Consultants and search them by parameters.

Consultant parameters:

• First Name, Last Name
• Email,
• Date of Registration,
• Skills.

By default, Consultants with the maximum registration date are displayed first.
After clicking on the user's card his or her full profile is displayed, there is a possibility to view comments from other users.

For the Administrator, Consultant lock/unlock icon is available.
• Directory of Transaction

<картинка?>

Transaction parameters:

• Name of the Client,
• Name of the Consultant,
• Amount,
• Status,
• Flags of Voting,
• Date.

Possible filters for transactions viewing:

• Client,
• Consultant,
• Transaction Date, Period,
• Status of the Transaction

Only the Administrator sees all of the transactions,
The Arbitrator sees only those disputed in which he is appointed as the arbitrator.

For the Administrator and the Arbitrator, there is an icon for viewing the report on the consultation and explanations of the arbitration.
For the Arbitrator buttons for resolving conflicts are provided, and the resolution is registered in a smart contract using Metamask.
• Directory of Templates for Messages

There are templates for messages to be sent.
• Directory of Consultant Report Parameters

The directory contains the current set of parameters, and it is possible to add, edit and delete them from the list, with each parameter having a field type, a regular expression to test when typing, and a list of available values if the field type is a drop-down list.

MARKETING AND PRESENTATIONS

Our marketing department conducts research of the market of telemedicine services, prepares and sends out worldwide presentations to the telemedicine companies. Our managers are negotiating with many of the companies that are interested in our DocCoin telemedicine system.
Also our marketing department conducts intensive negotiations with associations of medical professionals around the world, because our system essentially helps medical consultants to easily open their own practice on the Internet without opening an office, allowing working from home office without looking for clients by advertising, because the clients will come to our DocCoin telemedicine ecosystem to select consultants from the list provided by the ecosystem.

CONCLUSION

We have done a lot of work.
The company's website has been updated with new materials and made more user-friendly.
For the smart contract, an algorithm is written, implemented, and ready for beta testing.
The same is true for the remote consultation system for telemedicine, which is a large and rather complex software package. The first working version of this complex has already been created, it will be improved and developed further.
The marketing department conducts extensive work to attract partners for testing and further use of the DocCoin telemedicine ecosystem.
The work goes according to plan, according to the "road map", which is published on our website. We stick to the planned schedule.
We are confident in the future of our DocCoin telemedicine ecosystem. It is necessary for people, and soon it will take its important place in the global world, we are sure, we are working on it.