IOTA Hackathon: Fraud Detection (Part 2)

This is the second installment in our posts about the experiences of the „Freedom Pass“ team during the IOTA Hackathon. In the first post (found here), Kira set the stage and explained the current issues of the London Freedom Pass. In this post, we’ll get a bit more detailed with regards to how we built the project.

DISCLAIMER: Even though the project is called „Fraud Detection“ the technological focus is very much on IOTA and not at all on machine learning-methodologies or data science, as one would commonly associate with fraud detection and prevention.

After we’d narrowed the scope down sufficiently to what we thought would be achievable during a hackathon, we started getting familiar with the IOTA tangle. We followed this tutorial for making a simple transaction, written only a few weeks earlier but already with some modifications required. After having gotten ourselves familiar with the general concepts of the Tangle (much accelerated by a presentation and Q&A by Chris Dukakis of IOTA) we connected to a testnet node and started issuing transactions.

Before we get into the details of the project, I’ll make a short comment about the decision whether to run a full node, the IOTA Reference Implementation (IRI) or to connect to pre-existing nodes. In short, to run the IRI, one needs a complete Java Runtime Environment, which is one of the reasons why IOTA can’t be run on an IoT device at this point. Each node connected to the tangle exposes an HTTP API through which transactions can be issued. To set up an instance of the IRI, one has to acquire the addresses of the already connected nodes in the tangle. The recommended way to do this is by asking people in the slack-channel #nodesharing. Because of the above restrictions and our requirements in time, we didn’t think it would be necessary to run our own node.

Back to the task of solving the problem of fraud in the application process for the Freedom Pass in London boroughs. We settled for the JavaScript library since it does a lot of the heavy lifting on top of the API and is by far the best-documented library. (The winning team used the mostly undocumented Python library and still managed to interact fairly smoothly with the tangle). The iota.lib.js implements both the standard API, some useful functionality like signing, unit conversion and reading from the tangle. In our project, we had set out to supply the following interactions between the tangle and our users:

  1. Register Doctor as a seed on the tangle
  2. Register Applicant as a seed on the tangle
  3. Perform a transaction for each certificate between the issuing Doctor to the Applicant.
  4. Verify that a certificate was registered on the tangle given a Doctor and an Applicant
  5. Read information off of the tangle about outgoing transactions from all Doctors

Given the above functionality, how could we leverage the existing IOTA library in the best way possible? Well, since smart contracts or most types of advanced transactions aren’t really possible on IOTA (yet), we will need some off-tangle processing, storage and UI.

For this, we implemented a backend and some wrapping to process the information from the applications. The server-side was written using Node.JS and the express-framework. To model the logic and structure of the database, we used MongoDB and mongoose. The MongoDB contained a simple key-value store, saving relevant applicant information. One could imagine that is could be upgraded to a graph-model to better mirror the tangle structure and to be able to more efficiently analyse connections between Doctors and Applicants, however, that was out-of-scope during the ~24h of coding we had.

In order for the user to interact with the tangle in an easy way, we built a small web-frontend. It allows the user to enter information about an application such as the national insurance number of an Applicant, postal code of the Doctor and Applicant, phone numbers, etc. At this stage, four things need to happen:

  1. The information is saved in the MongoDB-collection,
  2. seeds for the Applicant and Doctor are created based on an aggregate of identifying information,
  3. new test tokens are generated and sent to the Doctor’s account and
  4. an IOTA transaction is issued from the Doctor to the Applicant.

To save the information into a MongoDB-collection a controller instantiates and returns a new model containing the just entered data. It passes it on to the server.jswho handles the HTTP-requests from the client.

There is no dedicated IOTA API-call for generating seeds, but they do supply a command line command for generating a random seed. We made our seeds relatable to the private information by concatenating the private key with the national insurance number for the Applicants and the Doctor’s ID for the Doctors. After the seed was generated, a fresh address is created for each new transaction.

To make the functions from the iota.lib.js a bit more usable, we wrapped the existing callbacks-based structure in Promises. This allowed our code to become a bit more asynchronous than it is ‚out-of-the-box‘.

Here is an overview of the architecture:

„Freedom Pass“ System Architecture

Once the data and the transactions were issued, the next step was to provide a way of viewing the existing applications and certificates. So we created a second page of the UI for listing all applications with relevant information read from the MongoDB-collection.

UI for entering Doctor’s and Applicant’s data

This doesn’t, however, provide such a great way of finding the main type of fraud that we were considering, namely Applicants reusing information about Doctors. This makes it look like a single Doctor issued an unreasonable amount of certificates. A pretty easy case to catch, one would think, but considering it is a completely analog process done by on  paper in different boroughs by different administrators, it sums up to quite a large amount of faked applications. This is the type of fraud we focussed on in our processing.

So how can we in a user-friendly way flag cases that should be investigated? We chose the simplest option and created a second view of the UI where each Doctor in the system is listed along with the number of certificates they’ve, supposedly, issued. The list is sorted by the number of certificates issued. Here one could imagine making it a bit smarter by including the date the certificate was issued and creating a more differentiated metric of certificates per time unit, but it wasn’t in scope this time around.  If a Doctor issued more than 10 certificates, they were highlighted in red. A very simple but potentially efficient way of communicating to the user that something needs to be investigated. Of course, the number 10 was completely arbitrary and could have been chosen differently. In fact, to decide that number, one would have to, first of all, analyze historical data.

Hitlist of certificates issued by Doctors

To sum up, Team Freedom had a lot of fun and learned tons about IOTA, ideation, cooperation, and creation in a short time-frame. We managed to build a functioning Proof of Concept for how IOTA can be used for the secure issuing of medical certificates in order to prevent and detect fraud. The application to the Freedom Pass was done so that it would be easier to understand what was being done and why. But that does in no way mean that the base structure cannot be used for other purposes, in fact, it was written specifically to be general enough that it is also interesting in other areas.

Is this the only way that the problem could have been solved? No. Was it the easiest way of solving it? Absolutely not. However, we believe that only by experimenting and utilizing one of the few scalable and future-resistant distributed ledger solutions can we achieve applicability. There is, generally speaking, almost no distributed ledger application that could not have been done without the use of a distributed ledger, but it would have incurred great financial, organizational or trust costs. IOTA is a very cost-effective and scalable solution, but with the caveat that it is still in its infancy.

Freedom!
Team „Freedom Pass“ at the IOTA Hackathon in Gdansk, Poland

  Here is an overview of all reports on the IOTA Hackathon’s projects:

1st place – „PlugInBaby“:

…describes the idea and the pivot of the project
Team „PlugInBaby“: Open Car Charging Network (Part 2)
…describes the technical level and provides resources

2nd place – „Freedom Pass“:
Team Freedom Pass: Fraud Detection (Part 1)
…describes the high level of the project
Team Freedom Pass: Fraud Detection (Part 2)
…describes the technical level of the project

Medication Plans on The Blockchain – Building a Decentralised Application in Healthcare

The theme of this post is easily generalised to other use cases and serves as an example of how blockchain technology can shift power and trust in a well-established system, in this case the one of health care.

TL;DR

Medical prescriptions should be unified and digitalised. They should be resilient and controlled by the real owner of the prescription (and thus of the personal data). This can be achieved by a blockchain-based solution. A system of smart contracts in Solidity is proposed which achieves this and furthermore is modular and update-able. Some general advice on designing a blockchain solution is given.

What’s the problem?

How many of you know what iatrogenic illness means? I confess that prior to writing my Master thesis upon which this post is based, I also had no idea. So, to not keep you waiting, here’s the definition from Merriam-Webster:

ioatrogenic: induced inadvertently by a physician or surgeon or by medical treatment or diagnostic procedures

from the Greek word for physician (iatros). Add an illness to that and you have an illness caused by a physician. Now, it sounds like an oxymoron, but it is in fact more common than we would of course like to be. You can divide the causes for iatrogenic illness into so-called Adverse Drug Events (ADE) and, to be completely MECE*, other reasons. Other reasons would include things such as rough examinations, surgical errors (there’s a reason they draw arrows on the limb to be amputated) and so on. ADE includes all injuries or complications caused be medication, be it the wrong medication, drugs interacting in unintended ways and so on. [1] ADE has shown to be the most common cause of injury to hospitalised patients, and furthermore, the most preventable one.

Where is the problem coming from?

In fact, computer-based prescribing systems have been shown to decrease medication errors by 55% to 80% in a study from 2004. [2] It does not, however guarantee that the most severe of those medication errors are prevented by the usage of an IT solution. Among ADE’s, the most common form of avoidable medication errors are prescribing errors (i.e. an error made somewhere in the process of getting a drug to a patient). There is a list of sixteen classes of these prescribing errors, but basically they boil down to:

  • Knowledge deficiencies – among doctors, patients or pharmacist about drugs, other parties, et c.
  • Mistakes or memory lapses – e.g. a patient forgets what medication he/she is already on
  • Name-related errors – complicated-sounding substance gets mistaken for other complicated-sounding substance
  • Transferring errors – information is missing or incorrect once the order arrives at the pharmacist
  • ID checks – patient, doctor or pharmacist ID isn’t properly verified
  • Illegible handwriting (!)
  • Wrong type of document filled out

These errors all illustrate why prescribing errors are so common, but also why they should, to a large extent, be avoidable. [3] The thing is that, considering the current rate of prescribing errors causing damage or danger to patients being relatively low (ca. 2% [2]), its importance is overshadowed by more clinical research in medicine and is thus being overlooked by the research community and public in general. One reason for this could be the wide-ranging competencies required to implement a system for decreasing the rate of prescribing errors to zero. To do such a thing, one would require technical expertise within security and privacy as well as all the various skills for application development, one would also require medical and pharmacological knowledge, and essentially, one would need to have experience within information systems management.

A step in the right (digital) direction

To combat prescribing errors, many public health systems require or recommend that patients with more than three different prescribed medications have a unified medication plan which should theoretically contain all prescriptions. The effectiveness and quality of medication plans was examined in 2015 by a group of German researchers. The results were scary. 6.5% of all medication plans examined did not contain discrepancies! Where discrepancies means differences in drug names, additional or missing drugs, deviations in dosage, et c. In spite of this, or perhaps to improve the quality of medication plans, a law was passed in Germany three months after the publication of the medication plan review, which makes it mandatory for all patients with three or more medications to have a medication plan. In order to cope with the slowness of technology adoption in healthcare, up until January 2018, there is no requirement that the medication plans should be digital. Thereafter they should be available on an electronic health card (eGK). [4]

Considering the different types of prescribing errors we’ve identified, it is not difficult to translate those into some type of requirements for a system to solve those errors. The resulting requirements happen to fit very well to a blockchain system with smart contracts, therefore we’ll propose a design of a system of smart contracts to function as medication plan. Let’s look at the errors one by one and explain which requirements fit to them:

Knowledge deficiencies

To resolve this error, data regarding patients and their medications needs to be unified, available and guaranteed correct. There shouldn’t be multiple versions with equal or uncertain amounts of validity. Additionally, there should be little chance of the data getting lost or not available when it is needed.

Mistakes or memory lapses

It is completely human and expectable that a patient taking many different medication can’t remember the details of complicated names of each substance. This can be solved, however, by the unification of medication plans and assurance that all prescriptions are correct and active.

Name-related errors

See point Knowledge deficiencies.

Transferring errors

Through the unification of the various systems available currently, the process of transferring prescriptions would be simplified.

ID checks

Through the digitalisation and implementation of a permissions management system patients would only need some type of identification (could be biometric) to collect their medication.

Illegible handwriting

Assuming the doctor enters the prescription into a digital system and doesn’t write with pen and paper, this problem is practically eliminated.

Wrong type of document filled out

Again, through the unification of the different possibilities to prescribe a medication, there would be no such things as the wrong type of document. At least not inside the system.

Design choices in the solution

So what are the technical details one needs to consider when designing a blockchain-based system for a medication plan? I’ll describe the three most important design choices in this blog post. The three questions are:

  • Who needs to participate in the network?

In this case, the only users are doctors, patients and pharmacies. So to not take on additional risk regarding data exposure, only those who are on-boarded and verified through some separate process should be allowed to participate in the network. There are however some negative aspects of choosing a private or permissioned blockchain, one point being that there might not be enough active nodes to keep the consensus building at an acceptable fault-tolerance level at all times. This can be solve by some type of incentive or requirement that for example doctors keep a running node at all times. Another risk of running a private blockchain is that, when the amount of nodes isn’t very large, and the users consists of a specific group of people (such as doctors in Germany), then the risk of collusion becomes considerable. To combat this, the consensus-making should be well-spread geographically and demographically.

  • What data and functions need to be on the blockchain and what should definitely not be there?

In the case of a medication plan, the data which is required to be on the blockchain consists of three parts; user IDs, prescriptions and doctor/pharmacy permissions to prescribe/sell medications. Naturally, we can’t have plaintext information about patients and their prescriptions, even if it is a private network. Therefore, IDs are formed from a public/private key-pair (similar to bitcoin or ethereum), which should be generated by the user, on a user device. Prescriptions are only ever published on the blockchain as hashes, because even though the users theoretically are anonymous, it has been shown that Bitcoin transactions can be traced back to a person. [5] The permissions of doctors and pharmacies also need to be stored on the blockchain, in a smart contract to ensure that they aren’t manipulated or somehow overruled. Including permissions and sensitive data in smart contract means that extreme caution needs to be taken when programming them, to ensure that no syntactic or logical mistakes are made. The functionality needed on the blockchain is basically complimentary to the data pieces, getters and setters. But additionally, permissions needs to be handled on-chain.

    • How should the smart contracts be written?

There are relatively few resources by experienced smart contracts developers on best practices for building smart contracts, but mostly the general advice for writing good code (failing loudly and as early as possible, commenting, etc.) should be followed. There is however, so much to say about specific smart contract programming that it will be more explained in another blog post. Here, I’ll just talk about architecture of the system of smart contracts briefly.

In order to be able to keep an overview of the smart contracts and functionality used in the application, they should be as small and simple as possible, thus facilitating analysis. Ok, so say that you have a fairly complicated (not in a computational way) functionality to begin with, then you separate it into multiple smart contracts and end up with maybe five to ten of them. How are you supposed to keep track of them and increase the modularity of you system? Enter the contract managing contract. [6] It is basically a contract to keep track of (and manage) the different contracts in your system, it logs the addresses and names of each separate contract and provides another contract, the endpoint of the user-facing application, with the possibility to access them.

Conclusion

Designing an application for managing sensitive personal information needs to be resistant to failure, privacy-preserving and provide accountability so that any changes to the information can be traced. A very relevant use case for such an application is a medication plan. A suitable system for building the application back-end, is a blockchain-based system of smart contracts. Smart contracts programming is a fairly new phenomenon and is based on decentralisation, therefore much thought should be given to how such a system should be designed. A possible solution was drafted above.

*MECE stands for Mutually Exclusive, Collectively Exhaustive

References

1. Tierney LM. Iatrogenic Illness. Western Journal of Medicine. 1989;151(5):536-541.
2. The Epidemiology of Prescribing Errors, The Potential Impact of Computerized Prescriber Order Entry. Anne Bobb; Kristine Gleason; Marla Husch; et al, Arch Intern Med. 2004;164(7):785-792. doi:10.1001/archinte.164.7.785
3. Prescription errors in the National Health Services, time to change practice,
Hamid, Harper and Cushley et al., Scottish Medical Journal. Vol 61, issue 1, pp. 1-6. 21.04.2016
4. Full legal text available at: http://www.bgbl.de/xaver/bgbl/start.xav?startbk=Bundesanzeiger_BGBl&jumpTo=bgbl115s2408.pdf
5. Deanonymisation of Clients in Bitcoin P2P Network. Alex Biryukov, Dmitry Khovratovic, Ivan Pustogarov. Proceeding
CCS ’14, Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, Pages 15-29, November 03 – 07, 2014
6. Monax – Solidity tutorials, https://monax.io/docs/solidity/solidity_1_the_five_types_model/, Accessed on 15/05/2017.