Tag Archives: API Management

A Smarter Transport Management System for London with the Help of WSO2

Transport for London (TfL) has a daily challenge – to keep a city of over 8 million people moving around the metropolis. Its magnitude can neither guarantee the transport system will always absorb commuters nor give them a congestion-free experience. It is a place where the smallest of changes would have a massive impact on your journey. Citing an example, Roland Major, a former enterprise architect at TfL, says that a London Underground strike once saw a 3% increase in traffic and a staggering 90 minute increase in journey time. Estimates project a 60% increase in congestion around central London by 2031.

Given all these complications, TfL decided to become more intelligent with technology to reduce commuter times, make the roads safer for pedestrians, cyclists and drivers, and to slow the pace of traffic. Intelligence and data with a purpose are the buzzwords here. “We need better understanding of real-time demand. What insight can we get from our data, and how can we get innovative with all this information?” says Roland. He was actively involved with TfL’s Surface Intelligent Transport System (or SITS), a project that aims to better manage the city’s entire road space of pavements, cycle lanes, and motorways.

SITS’ business proposition is that it can offer billion pounds’ worth benefit to London by identifying delays in the road networks sooner than it is done at present: “We weren’t detecting incidents, and by the time we have detected them, they were already over. With technology, we can see these incidents early. We recognized that the market can do sensible things with our data,” says Roland. For example, within the traffic light system in London, TfL manages an estimated 7,000 junctions around the city and 14,000 magnetometers detect millions of daily events. This data is discarded after analysis; however, if used, TfL realized that the response time to delays improved by 15 minutes.

TfL has a 10 year plan in place, with all the of different required components mapped out. Data analytics form the core of this operational model. Data is obtained from GPS systems and bus routes. The road incidents are logged and used to determine what additional information is needed to understand and manage each leg of commuter journeys. All the data is hosted on the cloud and currently TfL is in the process of adding these components to the framework.

TfL’s transport management system

London’s new road management system relies on WSO2’s API management, integration, identity and access management, and analytics products for the intelligent work needed. These products are deployed on a private cloud managed by WSO2. The starting point – LondonWorks, a registry of all road works and street related events, both planned and current, in the Greater London area. LondonWorks is used to assess road networks, coordinate the various road works to minimize congestion and for inspection, compliance, and monitoring. Maps and forms of type data have been integrated to allow entry of incidents into the system and their identification on the map.

As their model progresses, TfL has ambitious plans for all the data they have streaming in – big data analytics to give them more insights to road movements, which will enable them to give the necessary alerts and empower them with smarter ways to deliver better, safer commuter experiences for London.

Watch Roland’s presentation for more details on TfL’s plans for London.

Explore the WSO2 middleware platform with its offerings in API management, integration, identity and access management, analytics, and IoT.

Did you know that WSO2 won TfL’s data analytics Hackathon contest? Learn all about it.

Building a Cloud Native Platform for CitySprint’s On the Dot Delivery Service

Picture a scenario where you are analyzing the results of a marketing survey which shows that a high percentage of consumers prefer same day shipping, online tracking of their orders, choice of shipping options, and deliveries within a specific time slot. Then you find out that retailers already fulfill around 65% of these needs, but there is a gap in the market, a gap that you can fill by offering a novel service. This is precisely what UK-based logistics and delivery service provider, CitySprint did when they developed the On the dot delivery service, which allows shoppers to receive their orders during a one hour time slot of their choice without extra costs.

“We wanted to positively disrupt the time slot delivery space. In doing so, we wanted to build an API ecosystem that sparks interaction, open new channels and reach new streams of revenue,” says Eduard Lazar, Senior Solutions Consultant at LastMileLink Technologies (a CitySprint Innovation Lab). At the heart of of this project was generating value for users and driving innovation, “On the dot is all about convenience for consumers, be it as a fulfillment method or in terms of collection and delivery time slots. We also wanted to simplify integration and create a developer community through our API ecosystem,” he adds.

Defining the key challenges was one of the first steps before introducing On the dot to consumers. To begin with, CitySprint had to move their data centers to the cloud in order to become a cloud native platform. They also had to create open RESTful APIs, enable identity federation, foster innovation so that it can result in a community of developers who will think up new marketable ideas and simplify integration. Selecting open source software is one of main tenets at CitySprint, and as such, they set about developing an open source platform made of WSO2’s API management, integration and identity and access management capabilities, using a DevOps approach. Meanwhile, the architecture was developed using Apache’s Tomcat and Cassandra, and WSO2Carbon used for continuous deployment.

By placing API management at its core, CitySprint has been able to achieve the required functionality and formed their innovation community (an interesting anecdote on the latter, a TechSprint event was organized where high profile companies sent teams of developers to CitySprint to build innovative products within 24 hours. Results have been quite amazing with an added bonus of introducing CitySprint to new leads).

From a business perspective, implementing this project was primarily underpinned by issues of costs, in addition to those of speed, integration, lifecycle, and skillset. When CitySprint introduced more complexity into the system, this also meant they potentially introduced a time lag. Yet, can this platform control costs through simplification and reuse? Is there a way to save time by simplifying integration? Is the skillset future proof? Can they model the whole lifecycle?

The result – On the dot – answers all the above with a yes. On the dot cloud native platform has empowered CitySprint to enter the market with an adaptable platform, which allows developers to self-sign and begin using the APIs, it is integrated as there are multiple systems working together, they have also connected data and devices, integrated platforms with those of their partners, and connected the user experiences of both customers and partners. Following their successes in the UK, plans are underway to make On the dot a global phenomenon and CitySprint is certain they can achieve this with the right technology.

If you need more details on how CitySprint made On the dot, watch their presentation.

Learn more about WSO2’s API management, integration and identity and access management capabilities.

UNRWA and Capgemini: Creating a Refugee Centric Data Model for Better Insights

The United Nations Relief and Works Agency for Palestine Refugees (UNRWA) has over 5 million registered refugees requiring education, healthcare and social safety assistance, among others. UNRWA aids refugees across five countries – namely Lebanon, Jordan, the West Bank, Syria, and the Gaza Strip which has over 500,000 students, 692 schools as of now, and hundreds of primary health facilities.

In order to automate several processes across the region, the team based in Gaza had already developed the Education Management Information System (EMIS) consisting of three modules (students, staff and premises) and reporting tools. EMIS captures information and manages the educational progress of half a million students, by integrating data from registration, health, facility management and human resources systems that are already in existence.

Yet, given the numbers and scale of its operations, a central data model that has the capacity to integrate data from several entities was the need of the hour to support its regional operations and EMIS. To transform their information management system, UNRWA and Capgemini used WSO2 technology to create a model which mirrors UNRWA’s organizational ethos – placing the refugees at the heart of all their operations.

“The technology is there, but it’s really about the people,” says Francesco Lacoboni, Managing Consultant at Capgemini. Accordingly, the main drivers of the new UNRWA Enterprise Architecture are built upon the strategic principles of people, information, collaboration, and security. People influence how the information is created, managed, and consumed. The platform is an information-centric one – rather than managing documents, it manages open data and content. Its shared approach design aims to improve collaboration, reduce costs, maintain standards, and ensure consistency across the board. Security and privacy features for data protection round off the principles of this platform.

Before the new model was introduced, there was a time where the information that streamed through the system was physically replicated via the transaction log. For reasons of ease and efficiency, UNRWA and Capgemini decided to provide a common set of APIs to all the developers, not only to fulfill the needs of the specific application, but to also create the framework for future use of this semantic concept. Every entity has a credible API that can be used to navigate the knowledge, eliminating the need to design a new API. The resultant Common Data Model (CDM) was created using OWL (Web Ontology Language), and its architecture and governance completed using WSO2’s integration and API management platforms.

For Luca Baldini, Chief of Information Management Services at UNRWA, it was the first time such an approach was used and now that it has been rolled out, he praises its benefits: “The new model has been very productive, as it created a common language between IT specialists and our business representatives. We can use different kinds of technology for data retrieval and distribution.” Francesco believes one of the main benefits of the new model is that it helps increase the transparency of UNRWA’s operations. Now that the new model is successfully in practice, analytics is the next frontier and they hope to leverage WSO2’s analytics capabilities to meet their requirements. Spurred by the possibilities of analytics, plans are in the pipeline to use this data model along with unstructured data provided from the field to improve operations and add further value.

You can watch Luca’s and Francesco’s presentation at WSO2Con USA 2017 to hear more about their project.

Learn more about WSO2’s integration, API management and analytics capabilities if you would like to use them in your enterprise.

Brigham Young University: Enabling API Discoverability and Data-driven Business Insights with WSO2

Brigham Young University (BYU) began their API Management story 2 years ago when they decided to adopt an API-first architecture that follows a governed process. With over 451 APIs for both external and internal customers, and several development teams working independently of one another, Brayden Winterton (Software Engineer at BYU) likens its management akin to running a small city.

Modernizing their API management was a result of a problematic system that existed at that time. For one, the API manager in existence was closed-sourced and used an old, unsupported third party code. Adding some confusion to the mix, BYU had two versions of their API infrastructure in production – having started with one version, developing a second version along the way and the migration process forever a work in progress. Due to a memory leak, boxes had to be rebooted nightly (if not all API traffic ceased by noon the next day). Furthermore, there was no monitoring of API usage and the documentation support was out of date. In short, BYU was in a “serious situation” to use Brayden’s exact phrase.

Faced with all these scenarios, BYU was looking to implement a new API management solution. A key need was to create a centralized repository for all the APIs at BYU, which enables developers to search for and find all the available APIs, in addition to the respective authorization processes. A seamless transition without drastic changes to their existing developer work was another one of their important requirements. Low latency, up-to-date documentation, integrating with legacy systems and the ability to keep track of all the APIs being utilized completed their wish list.

To implement their requirements, they turned to WSO2 API Manager and WSO2 Identity Server. BYU now has subscriptions that allow consumers to get through to the API and subsequent monitoring; they were able to integrate all legacy systems with message mediation, minimized latency even while mediating quite heavily and of course, it is all open source. The BYU model works on open subscription first, however there are instances where they have needed to block a subscription until further approval was granted. They have been able to do this with an open source platform. Another huge plus has been the ability to utilize industry standards and BYU even got something that was not available to them previously – monitoring and analytics to support their business decision making. Improving discoverability and keeping the documentation up to date were the last pending issues for BYU, ultimately solved by the BYU developer portal in the second stage of their implementation.

“Our developers who have migrated are having a fantastic experience. They’re able to use things in a standard way, able to find the documentation they are looking for, utilize libraries, things aren’t drastically different, all of their old systems are continuing to work and they are getting a lot better reliability out of what they’re trying,” says Brayden. Adding to this success, BYU has seen higher API consumption as of late and with the improvements in place, Brayden is excited about the future.

If you would like to listen to Brayden’s full presentation at WSO2Con USA, click here.

Learn more about the WSO2 API Manager and WSO2 Identity Server if you haven’t tried it out yet.

Cashing in on APIs – Leveraging Technology to Boost Your Business

Even if you’re not an excessively tech-savvy individual, you most likely would have used a mobile application in your mobile device via an internet connection, used a Gmail client, Twitter, Facebook, or mobile apps, or purchased something online. In a tech world, you’re already reaping the benefits of application programming interfaces (APIs). The use of APIs is becoming even more popular today as service providers are scrambling to embrace the Internet of Things. With the availability of new tracking devices, smart homes, smart vehicles, mobile phones and tablets, consumers now have more options on how they consume applications.

Let’s take a step back and try to understand what this all means. An API is a term that’s used to denote a well-defined interface to access certain resources – in other words a service available to an end-user. If you haven’t worked with web APIs before, you may think it’s a type of service exposed over the Internet to perform certain operations. APIs are the foundation of today’s software engineering industry and enterprises are jumping on the bandwagon to reap the benefits of using them to integrate and automate to make their online services more appealing and user-friendly to end-users. Well-designed APIs will enable your business to expose content or services to internal and external audiences in a versatile manner. Today, most organizations use APIs to build their solutions internally and expose these services to the world at large. APIs will immensely benefit both service development teams as well as service consumers.

A good, yet simple example that illustrates this well is a weather update application that’s available on your mobile device. This application that typically runs on a device will not be able to provide weather forecasts of a specific area without connecting to an external service. However, it can call a GPS device on your mobile device or request the user to retrieve location coordinates of a specific area for which you want a forecast. Once you’ve defined your geographical location, the mobile application can simply call a weather service API and request the required information. What’s important to note here is that you don’t need to perform any complicated tasks, do calculations, or run an analysis on the mobile device. You can simply push relevant parameters to an API and obtain the results you want.

If you view this same example from one level up, you’d see that there’s a client application and a service and both of these are connected by an API. That’s essentially what an API does; it can integrate your services, data, content, and processes with external parties in a very effective and efficient manner. So, what’s the difference between services and APIs? Essentially, the functions of both are the same, but a slight differentiator would be that an API would generally have a well-defined interface to its services. That said, there’s a notable difference between managed and normal web APIs/services. Managed APIs are often enriched with additional features on top of a standard API or service. These are referred to quality of services or QoS. Common QoSs include security, access control, throttling, and usage monitoring. Security forms the foundation any API infrastructure across the entire digital value chain. Malicious users can access your systems the same as legitimate users would, therefore it’s important to enable security at all points of engagement. Usage monitoring helps enterprises to improve their APIs, attract the right app developers, troubleshoot problems and, ultimately, translate these to better business decision.

Boosting efficiency to become more competitive

Enterprises too are seeing the potential benefits of APIs to propel business growth, irrespective of the size and nature of the business and the industry they operate in. The key is to get started now to be able to maintain a competitive edge. A typical example is the extensive use of APIs in the hospitality industry; for instance, the owner of a restaurant or a small hotel would operate a simple website and some internal services. But at some point, when the business grows, they cannot maintain the same internal system and work with external parties. At this stage, business owners would need to think about consuming external services and exposing their services to the external world. And that’s when APIs and API management solutions come into play.

Large, global companies in the financial, transportation, logistics, and consumer sectors have already started to expose their systems and services to the outside world as APIs. The real benefit lies with being able to seamlessly integrate internal systems with those external ones to leverage benefits like creating properly structured services that are synced within the company, e.g. human resources department exposing non-sensitive employee data to other departments that need this information. A typical example is an online retail business that would need a payment solution to integrate with its system. Such a solution would not need to be implemented from scratch, rather the business can expose APIs via already available payment solution providers like Stripe, Zuora, or PayPal.

To explain this further, let’s consider a restaurant owner who can expose menus and ordering services via APIs. This will enable external developers to consume these APIs with their apps and incorporate the restaurant’s menus and services into the travel applications they’re building. When exposing APIs, the restaurant owner would need to consider throttling, a process responsible for regulating the rate at which the application is processing, as well as the security aspect of exposing these APIs. On top of these, a service provider may need some insights into the usage of these APIs – for instance, details about service consumers (like which apps have been invoked more), usage patterns (most popular food types), traffic patterns (peak order times), etc in order to make certain business decisions and make the service more efficient. For this, you might need sort of analytics and usage monitoring capabilities as part of your overall API management solution.

How Internal Services Can Expose Services to External World Via APIs

how internal services can expose services via APIs

Ultimately what you achieve in terms of business benefits is brand awareness by becoming a smart business. Moreover, in addition to profits gained from direct API consumption, users can earn additional revenue by charging users for API/service usage. This concept is known as API monetization and most API management solutions already have this feature in-built as an extension, enabling creative users to turn cool ideas into revenue generating APIs within minutes. And open source products have proved to be most useful to meet all your API management requirements as its cost effective and easy to deploy.

Will Google Leave On-Premise Apigee Customers Behind?

By now you all know that Google intends to buy Apigee. So what does this mean for their customers? All we can make are assumptions, but the future doesn’t seem too bright. Firstly, customers with SaaS services on Amazon Web Services will most likely have to move to Google’s cloud platform. But this isn’t the biggest issue. It seems plausible that their on-premise customers will not be the highest priority because Google doesn’t have an enterprise on-premise solution, nor does it seem they will create one now.

So what will be the fate of on-premise Apigee customers?

We offer an appealing alternative. WSO2 API Manager offers a rich feature set and adaptable architecture encompassing advanced platform capabilities such as real-time analytics, API governance, and complex back-end integration.

Our roots lie deep in open source software, we’re committed to both on-premise and cloud solutions and offer commercial support at a reasonable price. If you are an Apigee customer who’s concerned about what the future might bring, now is a great time to look at WSO2!

We are serious about helping you fulfill the promise of the API economy. Check out our limited-time offer specially crafted for you. With free subscription periods and discounts, this is an opportunity you won’t be able to refuse!

WSO2 API Manager for Small and Medium Enterprises

WSO2 API Manager provides a very light-weight, robust and a scalable API management solution for organizations who want to manage APIs. WSO2 API Manager comes as a single product distribution but has five different components and can be deployed as individual components allowing greater flexibility in deployment while adhering to internal security policies of the organization. Running WSO2 API Manager as components allows more flexibility when scaling the solution and optimizes the resource usage.

WSO2 API Manager is deployed as a distributed deployment at many large organizations that expose APIs for both internal and external service consumers with millions of API calls serviced during a day. These organizations rely on WSO2 API Manager to deliver critical services to its stakeholders, which has a direct impact on their business operations. A distributed deployment can typically cater over 2500 API calls a second which is a staggering 200 million+ API calls a day.

Even though this kind of a requirement holds true for large-scale organizations, there are many organizations who need to start small and want a simple API manager deployment to support their requirements. WSO2 provides two solutions for such customers.

  1. On-Cloud – WSO2 API Cloud, which is a subscription-based API manager solution that you can subscribe to and pay based on the API usage. WSO2 API cloud offer plans ranging from 250, 000 to 50 million API calls a day.
  2. On-Premise – WSO2 offers an all-in-one API manager deployment pattern that allows you to deploy the WSO2 API Manager on-premise as a single instance. This type of on-premise deployment can support up to 500 API calls a second (nearly 43 million API calls a day). More details on this option are given below.

An all-in-one API Manager deployment has i5 components (Gateway, Key Manager, Store, Publisher and Traffic Manager) deployed inside a single product distribution. The deployment is very easy to setup and WSO2 provides a very comprehensive setup guide1 that provide step by step instructions on how to deploy the product. All-in-One API Manager can be deployed as a single active node, in Active/Passive mode or as an Active/Active node cluster. The diagrams shown below visually illustrates the 3 types of possible deployment patterns.

api-manager-for-smes-1

Fig 1: Single API Manager node

api-manager-for-smes-2

Fig 2: Active/Passive deployment

api-manager-for-smes-3

Fig 3: Active/Active API Manager deployment

It is recommended to deploy the API Manager fronted by a load balancer for all three deployment patterns. If APIs need to be exposed for external consumption it is recommended to use a Reverse Proxy or a Firewall along with the load balancer. A Reverse Proxy or a Firewall is required to route legitimate traffic from outside the network to the API Manager node that resides in the LAN. It is recommended to configure the API Manager to work with an external RDBMS to ensure reliability. If API Manager is deployed as an active/active or active/passive setup it would require a content synchronization mechanism such as Rsync2 (DeltaCopy or cwRsync for Windows) to synchronize APIs between the two nodes.

With the new all-in-one API Manager deployment pattern, there are multiple options for an organization to structure their deployment. If you are building a large-scale API Manager deployment then it would be recommended to start with a distributed API Manager deployment. However, if you want to start small and make the API Management platform available quickly this type of a deployment would be the ideal choice.

WSO2 API Manager 2.0.0: Better Statistics

Introduction

Any API management tool requires the ability to view statistics – accurately and with details essential to the operation of APIs. WSO2 API Manager 2.0.0 introduces powerful analytics features along these lines by using the capabilities of WSO2 Data Analytics Server (WSO2 DAS), bringing all API, application and subscription related statistics to one location.

image05

New additions

In order to help you make sense of these analytics, we’ve added the following graphs:

1.Published APIs Over Time

This graph can be used to check API creation rates. A user can check APIs based on the API provider or can view statistics related to all API providers.

image05

2. API Latency

The API Latency breakdown graph can be used to check time consumption for each level in the message flow. It shows total time taken to handle a request and provides the time each component spends on that request – for example, a user can check the amount of time spent on the authentication process and so on. This graph is useful for identifying delays in the API.

image013. API Usage Across Geo Locations

This graph provides statistics based on the location of the API request. It uses X-Forwarded-For header to identify the location of the user.

image06

4. API Usage Across Usage Agent

This graph provides information related to the access mechanism of the API, and helps provide insight into the kind of devices and platforms used to access the API – mobiles, computers and so on.

image08

We’ve also added an Applications Created Over Time graph under the Applications section. As with the API creation graph, this provides statistics related to application creation. Users can drill down the data based on the registered user and the API in question.

image02

In addition to these come the subscription graphs: Developer Signups Over Time and Subscriptions Created Over Time, both of  which are self-explanatory.

image00

image07

How These Statistics Work

WSO2 Analytics Server for API Manager is essentially a fully functional WSO2 DAS server.

image03

In a nutshell, WSO2 API Manager 2.0.0 sends the following event streams to API Manager Analytics:

org.wso2.apimgt.statistics.request:1.1.0

org.wso2.apimgt.statistics.response:1.1.0

org.wso2.apimgt.statistics.fault:1.0.0

org.wso2.apimgt.statistics.throttle:1.0.0

org.wso2.apimgt.statistics.workflow:1.0.0

org.wso2.apimgt.statistics.execution.time:1.0.0

org.wso2.analytics.apim.alertStakeholderInfo:1.0.0
The APIM Analytics Server process these events and writes the summarized data to a shared database. WSO2 API Manager then queries statistics from this database to display in the API Manager Publisher and Store.

Footnotes

One significant change in WSO2 API Manager 2.0.0 statistics is the removal of the graphical user interface (GUI) for configuring statistics. In WSO2 API Manager 1.10, a GUI was provided to handle this DAS-related configuration. We’ve moved this functionality back into the api-manager.xml file.

We’ve also taken out the DAS Rest client – with 2.0.0, the default and only implementation is APIUsageStatisticsRdbmsClientImpl, which uses an RDBMS client to get data from the database.

Since this is essentially a DAS server, you can use features such as gadgets and realtime analytics (using Siddhi) for better or more complex visualizations of the events sent from WSO2 API Manager.

Managing Identity Across the Internet of Things

 

network-782707_960_720 (1)

It’s estimated that at least 50 billion devices will be connected to the Internet by end-2020. That’s more than six times the entire population of the world! With this rapid increase of the Internet of Things (IoT), the concept of identity management has extended to the Identity of Things (IDoT).

WSO2 Director of Security Architecture Prabath Siriwardena wrote a white paper that explores the benefits, risks and challenges of implementing an IDoT solution based on the concept of “connected identity”.

He explains that through IDoT, organizations can assign unique identifiers with associated metadata to devices, enabling them to connect and communicate securely and effectively with other entities over the Internet. Your ultimate goal is to reach out to as many customers, partners, distributors, and suppliers as possible that would result in more business interactions and revenue growth. This would greatly increase the number of external digital identities that interact with your enterprise. An external identity provider can be treated as an identity silo that shares its identity data or IDoT via APIs. You first need to trust the identity provider in order to accept the given user identity. Beyond this, you need to speak the same language to transport the identity data. If not, you need to either fix the identity provider’s end to speak the same language or do the same for your own enterprise.

This is not a scalable approach, and will eventually end up in a spaghetti identity anti-pattern. To avoid this, you should build a protocol-agnostic security model. With the identity bus or identity broker pattern, your enterprise isn’t coupled to a specific identity provider or a given federation protocol. The broker maintains the trust relationships between each entity as well as identity tokens between multiple heterogeneous security protocols. This creates a common, connected identity platform that enforces controlling, auditing and monitoring of identities.

Some benefits of this pattern include

  • Frictionless approach to introducing new service and identity providers and removing existing ones.
  • Easy enforcement of new authentication protocols.
  • Ability to perform claim transformations, role mapping, and just-in-time provisioning.
  • Centralized monitoring, auditing and access control.
  • Easy introduction of a new federation protocol.

When implementing an identity broker you need to follow certain fundamentals. It needs to be federation protocol, transport protocol, and authentication protocol agnostic. Additionally, it should provide the ability to perform claim transformations, home realm discovery, and multi-option and multi-step authentication, among others.

WSO2 helps you solve identity management needs across your enterprise applications, services, and APIs by utilizing the full breadth of the WSO2 platform. By combining WSO2 Identity Server’s comprehensive security model based on OAuth 2.0 with WSO2 API Manager, you can easily build an end-to-end API security ecosystem for your enterprise. Avoid vendor lock-in and enable integration across systems with WSO2’s open source model, which acts as a fully functional enterprise identity bus.

To learn more, download Prabath’s white paper here.

WSO2 and MedVision360: Delivering Healthcare across Europe

Jan-Marc Verlinden is the founder and CEO of MedVision360. MedRecord, their flagship project, is an eHR (electronic Health Record) system: everything from patient data to digital health apps, devices, wearables, companies and hospital systems are wrapped together, providing a single platform on which healthcare providers can build medical applications and expose data and services via APIs. Currently, the MedVision platform is used in over 8 large EU projects, including hospitals from Hannover to Rome to Southampton.

At WSO2Con EU 2015, Jan-Marc took the stage to explain how MedVision360 achieved all this: using WSO2 products at the heart of their platform, with expertise from our partner, Yenlo.

Inside the medicine cabinet

MedRecord was born of a desire to do better. Europe, says Jan-Marc, is aging; by 2020, there will be 3 working people to every old person. In China, this problem is bound to be even more serious. This is a huge challenge for healthcare.

Given the severity of this situation, one would imagine this problem would have been tackled ages ago. Not so.

According to Jan-Marc, there are a few major problems in the way of change coming in with effective use of ICT; cost, concerns – or technical ignorance- about privacy and data security, a lack of communication between ICT systems, and the human capital it costs for data entry.

There’s also the lack of financial incentives to do better. There’s no real incentive for doctors to change the way they work and to reduce those long queues to something as simple as a mobile app, especially given the costs faced.

MedVision360 built two stacks: the first, which they subsequently open sourced, uses XML for storing data – and a second, enterprise version, with better performance using PostgreSQL. Both are based on the CEN/ISO EN 13606 standard, which requires the platform to use a dual-model architecture that maintains a clear separation between information and knowledge.

To convey the depth of modelling involved in this, Jan-Marc used the example of blood pressure, one of the many measurements involved in the process of treating a patient.

image01
This is the type of semantic model template developed by the NHS (the National Health Services, UK).  The idea is that this delivers both the data needed and the context that a medical specialist would need to frame the data in. As the system consumes these archetypes, it becomes instantly proficient.

image00
However, due to different workflows and standards, a doctor in a country other than the UK might require a different version of things, as seen above; not just a 1-1 translation of terms, either.

Working with Yenlo, MedVision360 utilized the open source WSO2 API Manager, WSO2 App Manager, and WSO2 Identity Server to solve this issue. WSO2 API Manager is a complete solution for designing and managing the API lifecycle after publishing. MedRecord’s architecture uses API manager to expose the data in the MedRecord platform from the PaaS layer, while managing access rights. WSO2 Identity Server enables login through third party identity providers (like Google and Netherland’s UZI-pass), handling role based access control and providing an audit trail.

image003
Everything else – applications, websites – is hosted on this layer. Swagger and JSON make it easier to build validated apps. Paired with a drag-and-drop HTML5 tooling interface, developers can easily build applications by accessing functionality from APIs with a few clicks. Hooks to portals like Drupal and Liferay allow better, device-independent presentation of content.

This opens up possibilities even for integration with Google Fit or Apple Health Kit. Google Fit, for example, collects data on the patient walking and so on; while that’s not relevant for a doctor, who’s more concerned with the patient not walking, parsing and analyzing the data would allow medical professionals to keep an eye on their customers’ health.

Healthcare is a very serious business, and at WSO2, we’re glad that providers like MedVision360 – and their clients- have chosen to trust our platform with the lives of others. To examine the full video of Jan-Marc Verlinden’s talk, click here.

At WSO2, we’re committed to making our platform better. To check out the components that MedVision used so successfully, visit the WSO2 API Manager, Identity Server and App Manager pages.