Q: Which technologies do you use for which purposes?
A: MAM for claims streams, Android for an example App, Bluetooth for communication between Raspberrry Pi and Smartphone, IOTA as persistence layer, Raspberrry Pi as a car’s board computer.
Pac-Man on Wheels, the winners of third place (for USD 1 000 + 15 000 XSC tokens)
Democratize autonomous driving by crowdsourcing and gamifying the data collection via IOTA Tokens
Q: What problem does your project solve?
A: In order to empower autonomous driving hundreds of thousands hours of sensor data are required. Individual data acquisition without merging possibility is never able to gain the appropiate amount of data needed to secure all driving scenarios. This can only be achieved by crowdsourcing the data by incentivizing road users with IOTA Tokens. A decentralized market place ensures the complete data availability.
Q: What expertise and roles did you have on your team?
Dr. Simon Hassannia: Head of Business Innovation and Automotive Industry Expert
Martin Mihaylov: Computer Vision & AI Engineer, Entrepreneur, Designer, All things tech enthusiast
David Hawig: Iota, Ipfs and Ntru C# Developer
Dr. Simon Hassannia: Head of Business Innovation and Automotive Industry Expert
Martin Mihaylov: Computer Vision & AI Engineer, Entrepreneur, Designer, All things tech enthusiast
David Hawig: Iota, Ipfs and Ntru C# Developer
Q: Which technologies and tools did you use in your project?
A: NTRU for encryption, IPFS for decentralized file storage, IOTA for immutable decentralized data exchange and monetization, Xamarin for multi-platform application development
After we finished the Blockchained Mobility Hackathon with the 3rd place our team quickly set up communication channels to stay connected. Although our team has just found itself on the Hackathon we have a very strong attitude our project will successful be enhanced and implemented now. Because of the perfect mix between software and business developers and the seamless collaboration inside the team we have a strong starting point now. By attending at the DAHO.AM conference right after the Hackathon we received positive feedback from several attendees and company representative to have found a well-fitted business case here. The strong interest in “Pac-Man on Wheels” strengthened us once more to proceed with the project. We already spoke to interested companies and investors at the DAHO.AM and figured out some approaches how to get going. We are still in negotiations if the project will be kicked off as a start-up or, which is actually more likely, integrated into a project of an existing company. Since nothing is settled yet, we appreciate and want to encourage any interested party to get in touch with us to discuss common realization possibilities.
The winning team received USD 5 000 + 50 000 XSC tokens and the opportunity to pitch their project to the IOTA Ecosystem Fund for 50.000 USD.
“In our vision we created the first Open Mobility Marketplace for IOTA – by enabling mobility provider companies (B2B) to publish mobility services offers (B2C), customers to search for them and conclude contracts in an easie way.”
Q: What problem does your project solve?
A: The API reduces hurdles to assimilate IOTA in existing architecture and facilitates mirroring of services and physical offer’s digital twins into an IOTA-based open marketplace.
Q: What expertise and roles do your team members have? Alexander: Experience: Business Practioneer & Innovation Specialist, IT educated, working experience in Automobility, Finance, E-Commerce Role in team: Scrum Master, Platform- and Business-Strategist, Product-Development
Benedikt:
Experience: Reseacher in engineering, focused on smart mobility solutions
Role in team: Reviewing solution space, creating backup strategies
Christian:
Experience: Web Services, API architecture and design, JVM
Role in team: Backend/Middleware Development
Fei:
Experience: Backend & Fronted Senior Developer
Role in team: App Development, IOTA-Interface
Stefan:
Experience: Bridgebuilder between business & development, with mobility business and FrontEnd, Backend, IOTA & Ethereum development experience
Role in team: Mentor, Product-Development, Website FrontEnd, IOTA-Logic
Q: Which technologies do you use for which purposes?
A: Java: Backend/Middleware Technology Spring Boot: Server Environment Swagger: Automation and Infrastructure NodeJS: IOTA APIs (publishing mobility offers, retrieve receiver address from Tangle, and send transactions requests) JavaScript: Website Frontend IOTA: DLT
We are proud to support FC Bayern, Germany’s leading soccer club on their Hackathon:
Thinking of fan experiences and services in a new way. Testing and applying innovative and new technologies within and outside the stadium. Bringing the emotional connection of our club to life even more through technology and digital infrastructure. Learning from each other and creating new things together.
For the first time, FC Bayern Munich will host, together with its fans, partners, leading experts, start-ups and students from all over the world, the #FCBayernHackDays to learn together, face new challenges and to research new innovative possibilities.
The IOTA Hackathon took place from Nov 17 to Nov 19 in Gdansk, Poland. Software developers from all over Europe came together to put to test the IOTA Platform with various use cases. The event was sponsored by IOTA, Baltic Data Science (blockchain and big data service), Datarella (blockchain and big data consultancy) and Bright Inventions (mobile app development). Four teams of developers and software experts formed around various use cases and competed for 4,200 IOTA in prize money.
This article describes the lessons learned by the “Freedom Pass” team, which Kira Nezu from Datarella coached. The technical part of the lessons learned can be found here “IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)” by the team member Jonatan Bergqvist. The team placed 2nd in the competition.
1. The Task
The team was joined by Bogdan Vacusta, who brought a real-life challenge from the London Council to the IOTA Hackathon. London Councils issue “Freedom Passes” to disabled residents which allow them to use public transport within the city free of charge. Prior to the issuance of a Freedom Pass, one must obtain a doctor’s certificate to prove disability.
Pizza boxes served as flipcharts for use case scenarios
Unfortunately, scammers have successfully been photoshopping doctor’s certificates for perfectly healthy London residents. No one knows for sure how many Freedom Passes have been issued under false pretenses but the number is likely in the thousands. London Councils have no procedure in place to verify if a certificate has been faked. A simple alert, when one doctor has issued an unusually high number of certificates would be a huge step in successfully detecting fraud. This step alone could save the public tens of millions of Pounds per year with the help of IOTA.
London Councils loose tens of millions of Pounds per year to fraud
The team’s task was to build a Proof of Concept (PoC) to prevent fraud. So, how can IOTA be used for fraud detection?
2. The Solution
The team decided to create a transaction from the doctor to the applicant, thus certifying the disability of the applicant on the IOTA Tangle. If an anomaly in the number of issued certificates of a doctor occurs, the system alerts the London Councils.
In an ideal scenario, the doctor would issue this digital certification from an app (mobile or web based), signing the transaction with her private key (this measure would actually help prevent fraud). Given the short timeframe at the IOTA Hackathon (less than 24h), the team chose to create sample data and to carry out the transaction on the doctor’s behalf for the PoC. A local database would be fed the details of the doctor and the applicant, as to identify them. So, the system for the PoC was to include the following components:
An input form for doctor and applicant data
An interface to the IOTA Tangle
A database with doctor and applicant data
A backend which analyses the data
A frontend for the London Councils with a list of alerts
System Architecture for fraud detection with IOTA. From the doctor’s ID and applicant’s National Insurance Number, a Seed is generated (you can think of a “Seed” as a key to access your data on IOTA).
3. The Process
Here’s is how it works:
1. Entering the data
The doctor’s and applicant’s data is entered via a web-based user interface (the team actually populated the database by writing a JavaScript method that wrote the fake data directly to the database, so this UI – although functional – was not needed for the PoC. You can learn more about this in part 2 of the lessons learned):
User interface for entering application data
2. Certification
The data is written to the local database. Simultaneously a transaction – symbolizing the disability certificate – from the doctor to the applicant is immutably written to the IOTA Tangle. The transaction ID is, in turn, written to the local database adding the ability to prove that the certification has taken place.
3. Analysis & Reporting
The backend analyses the data and alerts the officials in case of any anomalies. ie. (If one doctor has issued unusually many certificates within a certain time frame.)
Anomaly report for issues doctor’s certificates
What we learned
We completed our goal within the timeframe despite running into issues due to working with an immature system along the way. In the end, we managed to create a Proof of Concept perfectly suitable for the setting of the IOTA Hackathon.
We did run into a few issues along the way which must be addressed by the IOTA team in order to improve the system and make it fit for future use cases:
Speed of transactions: On the IOTA testnet we experienced long wait times when confirming transactions. Submitted transactions confirmed in ~1 minute, reading transactions took circa ~3-5 minutes or more depending on the amount of data. This may be a testnet issue independent of the mainnet.
The Documentation was not up to date, there was missing information and what documentation existed was somtimes misleading (i.e. Properties marked as optional are actually required, not obvious that a replayTransaction function creates a completely new transaction, sending a message instead of a transaction the sender is not documented on the tangle …)
Releases are not scheduled in advance, if an update is run during development, developers must adapt quickly to accommodate changes. A roadmap by IOTA for releases would be very helpful.
Node.js SDK is based on “callbacks” (an old technology standard), not on “promises” (current technology standard).
The API can easily be misused. Values and properties that shouldn’t be passed can go through without any error message. The API is missing descriptive error messages, leaving developers in the dark when it comes to hunting down bugs.
So, why IOTA?
Frist off, one might argue that this task could have been done with a regular database entirely. While this is true, a database is a lot easier to attack by hackers than a blockchain or tangle. Also, this kind of system could have been set up on a blockchain system s.a. Ethereum, why use IOTA? Well, the challenges blockchain systems are struggling to overcome are performance and scalability. Due to block sizes, transaction times constantly increase – thus making the systems less usable for scenarios in which transactions must happen near instantly.
IOTA helps to solve the problems of performance and speed of transactions. The team is in agreement that the IOTA Tangle and similar “non-block” chain approaches are likely to be most feasible to enable scalability in future. Also, an application using IOTA can quite easily be transferred to related use cases.
Conclusion
Would the team recommend using IOTA for fraud prevention?
The answer is Yes, if the long term goal is to further develop IOTA in general. The answer is No, if the system should be used in a productive environment at this point, since it is still immature. Alternative systems which currently are more mature and could be used for the task include Hyperledger Fabric, Sovrin and Ethereum. These blockchain systems pose scalability issues in the future, whereas development here is also ongoing.
The IOTA application “Freedom Pass” is very well scalable and transferable to related use cases. However, IOTA must undertake massive improvements regarding performance s.a. speed and documentation as well as for the API and SDK/node.js. If the above issues are continuously improved, the team recommends IOTA for further developing this kind of system for the public. IOTA promises future potential for the public for reconciliation of data, reduction of duplication, auditability, authentication.
Team “Freedom Pass” at the IOTA Hackathon in Gdansk (from left to right): Michał Łukasiewicz, Kira Nezu, Bogdan Vacusta, Jonatan Bergqvist, Victor Naumik, Rafal Hofman, Artem Goncharenko
The team was supported 24/7 throughout the hackathon by members of IOTA – many thanks Chris Dukakis, Lewis Freiberg and Andreas Olowski for their time and effort!
Here is an overview of all reports on the IOTA Hackathon’s projects:
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 ChrisDukakis 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:
Register Doctor as a seed on the tangle
Register Applicant as a seed on the tangle
Perform a transaction for each certificate between the issuing Doctor to the Applicant.
Verify that a certificate was registered on the tangle given a Doctor and an Applicant
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:
The information is saved in the MongoDB-collection,
seeds for the Applicant and Doctor are created based on an aggregate of identifying information,
new test tokens are generated and sent to the Doctor’s account and
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.
Team “Freedom Pass” at the IOTA Hackathon in Gdansk, Poland
Here is an overview of all reports on the IOTA Hackathon’s projects:
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.
BYOD – “Bring your own device” has recently become one of the most debated IT topics. BYOD means that employees use their private computers, smartphones, or tablets at their everyday workplaces and office desks, instead of getting seperate hardware, administrated by the company’s IT department.
More and more people want to use the same technology at work that they have chosen to use for their private purposes. In particular for younger professionals it becomes less and less accepted not to have all their tools at hand. Why would they let themselved get restricted to outdated operation systems, cheep hardware, and crippled internet access? Although some companies set up rules for their employees to use the devices of their choice, for most businesses the concerns outweigh any potential advantages.
What about cars? Some manufactorers provide rudimentary interfaces via bluetooth to connect some functionality of our smartphones with the car’s entertainment system. Most however seam to believe that people would still want to rely solely on the car’s onboard systems. Hardly any model has a proper place to put your device while driving. With our phone stored away in the usual bowl or compartment next to the driver’s seat, we couldn’t use it directly. We would have to access it via the car’s system that support only a tiny fraction of the phone’s functionality. To really use the smartphone, we still have to install cheep third party hands-free car kits.
Using our own mobile devices while driving is not just owed to our lazyness. While our own gadgets are up-to-date, the car’s technology will be totally outdated already when it first hits the road due to the long development cycles that are unavoidable in car construction.
Furthermore our apps have optimized user interfaces, continuously adjusted to users’ behavior. We might drive various cars, some we might not even own. How convenient would it be, could we use the same interface, no matter what model we would use?
Cars should support the technology of our choice. They should become agnostic to the way, people would want to navigate, listen to music, or even control the climate. Instead of forcing us to rely on their propriatory interfaces, they should give us as much freedom as reasonably possible to control the car with our mobiles. There might be limits due to security concerns.
Just last week, Jeep had to recall millions of their vehicles due to a vulnerability in the car’s computer system. System critical function could be accessed wirelessly. BYOD might be a good way to rethinking the architecture of the electronic systems. Accessing entertainment, air condition, and other passenger support systems is not as dangerous as controling acceleration, airbags, or the breaks. The different systems should be seperated physically. While the core of the car should be protected and not accessable without proper authorization, the peripherals should be as easy to connect as possible.
I have seen people taping their phones atop the car’s dashboard after loosing patience with the clumsy user interface of the built-in navigation system. Does anyone use these dinosaurs of consumer electronics anymore, at all? It is high time to change the way we, car companies treat their drivers. BYOD is a good first step.
Driving by car is strongly connected with a feeling of personal freedom. While we book flights just for one specific itinerary, and train tickets are usually only valid for a short period in time, we can get into our car whenever we want and drive any route that comes to our mind. Traffic jams, detours, or temporary road blocks apply to every driver the same way. And also speed limits or priority are not depending on how much we pay. This also holds true for toll that might be charged to cross a bridge or a tunnel – every driver is treated the same way.
However can we take this condition for granted that provides a network of roads in a neutral way to every user? Net neutrality is not a matter of fact in every industry, not even in all branches of mobility and logistics. Rail services e.g. charge special rates for express trains. While the tariff structure of rail companies are rather transparent in passenger services, this is not the case for transportation of goods. Depending on the buying power and on the negotiations of the customers’ procurement, freight will be transported timely or might travel rather slowly to its destination.
In telecommunications, the rate structure is even more notorious for its lack of transparency. Voice and data plans vary by orders of magnitude regarding bandwidth or duration that comes with different plans.
Net neutrality in telecom services became an important issue when ‘over the top services’ like Youtube or Netflix started to consume significant proportions of bandwidths. It became obvious that in the long run the carriers would be degraded to mere suppliers of infrastructure, just delivering a commodity instead of becoming ‘value added services’ that could charge their customers extra for their precious entertainment programs.
Until now, users pay for using the service in terms of just transportation of the data packages, no matter whats in the date. Since they are the ones who pay, it should thus follow consequently that the services they want to access must not be charged by the telcos or otherwise the service would be charged twice. In Europa as in many parts of the world it is still mandatory for telcos to act neutrally regarding the services requested by the users.
‘Managed services’ is what telcos are lobbying for in opposition to net neutrality. The argument goes that companies like Google (with Youtube in particular) or Facebook act like parasites on the infrastructure – skimming the profits without contributing to maintain it. Although there is very little facts provided to prove the allegations, it is not totally implausible. Advocates for net neutrality would respond though, that restricting net neutrality would give telcos a wrong incentive, not to invest in infrastructure to improve the situation, instead to shorten supply to be able to raise the price for services, or even worse, to exclude competition like Skype or Whatsapp and rather continue selling their own products like voice telephony or SMS.
With roads, the situation is fundamentally different. It is comparably easy to add new wires or build additional base transceiver stations to get more throughput for the network. It is much harder to build more roads, in urban environments it is often even impossible to increase the capacity for traffic. The consequence can be seen everyday: Traffic jams, overcrowded parking lots, polluted air. Worst examples are the big metropolitan centers in China and India, but the situation in most big cities in the US is also dire.
Road access without regulations thus leads to a classic example of the ‘tragedy of the commons’. Each driver will ask herself, why she should be the one to refrain from the benefits of individual traffic and switch to public transport. Some cities have already introduced special tolls, like the congestion fee for entering central London.
Autonomous cars and car sharing services when becoming broadly available would indeed offer another model. Telecommunication carriers license frequencies in the electromagnetic spectrum from the state, for which they have to pay a considerable sum. In return they can offer differentiated rate plans to their customers, and realizing a significant upside for themselves. Cities or whole countries could offer mobility carriers a similar deal: Car sharing platforms would rent capacity from the public, and resell their added value mobility service to finance the infrastructure. Rate plans could be fine tuned and automatically adapt demand. It might in this way just become to expensive to use individual means of transport for a commute that you could as well do in public transport or by bicycle.
That this is no far fetched business model at all is shown by Uber. Uber’s surge pricing anticipates such mobility services reacting elastically to actual demand. A major outcry followed when people became aware that instead of being charged a few dollars like usually, they would suddenly face payments more expensive by orders of magnitude.
Since the times of Henry Ford, individual traffic in the own car has been woven into the culture of most societies. It is thus not easy see opportunities and risks from a more distanced, more objective vantage. It will also not be easy to find the right rules and regulations to make a system of managed services for mobility fair and supportive to the economy.
The worst would be a contemporary version of highwaymen. Second worse however would be to go on and waste space, pollute the air, and jam the vessels of urban life like it can be seen in many cities today. Net neutrality for mobility will therefore become an important issue.
