Category: Case Studies

Pharmaceutical Supply Chain Track and Trace Proof-of-Concept

Posted on | by admin

Industry: Medical Prescription Manufacturing, Shipping and Logistics

Overview: Utilize Blockchain to create a trusted, immutable record for tracking shipments of highly regulated substances such as opioids.

Challenge: Tracking shipments of highly regulated products is often cumbersome with many parties involved in manual processes which opens the process up to a high potential for inaccuracy or fraud.

Solutions: Utilize a distributed ledger, on a Swirlds Hashgraph network to more accurately track shipments of highly regulated substances.

Technologies: Swirlds Hashgraph

 

Summary:

Within the pharmaceutical supply chain, regulatory compliance can place a massive burden on all parties. Many existing supply chains utilize manual processes that can drastically increase the possibility of manual errors and the potential for fraud. Since the introduction of Blockchain and Distributed Ledger Technology, Shipping, Logistics, and Supply Chain tracking have become one of the most popular use cases.

This proof of concept we were able to demonstrate that Blockchain technology is an ideal solution for tracking and compliance. Within the Pharmaceutical Supply Chain, Blockchain can be used to create more transparency throughout the process, in addition to an immutable record to ensure safety requirements and regulations are being met and are in compliance. It was built as a demonstration for applying Swirlds Hashgraph technology to the regulated supply chain space.

UX Examples of Reports from Solution

DLT Solution for Medical Credentialing Tracking

Posted on | by admin

Industry: Healthcare

Overview: The Customer wanted to integrate DLT into their existing medical credentials management platform in order to enhance trust in the information and reduce the amount of time required to verify credentials.

Challenge: Verifying medical credentialing is a very lengthy process in a highly regulated industry. In most cases the process can take weeks or even months to verify credentials, and many times has to be redone for verification purposes in each instance, such as medical professionals taking on other work-as is common in the field.

Solutions: Using the customer’s existing Salesforce application, TxMQ connected it to a distributed ledger network via REST API. The system includes an innovative mechanism for storing credential documents securely, with high availability.

Technologies: Salesforce, Swirlds Hashgraph, Java 8, CouchDB

 

Summary:

A Healthcare Practice Management organization wanted to add distributed ledger technology to their existing credential management platform. The client was looking for a way to shorten the lengthy credential verification process by enhancing trust in the credentials stored on the platform, while ensuring they were stored in a secure, tamper proof environment to avoid fraud and legal issues for their organization and clients.

A DLT solution quickly became the leading technology choice to underpin the solution and deliver the desired result. The Healthcare Practice Management organization had evaluated several blockchain-based platforms and found that they didn’t quite offer the needed stability, scalability, and high availability that was needed. For that reason they chose to utilize the technology from Swirlds, which uses Hashgraph with a unique Asynchronous Byzantine Fault Tolerant consensus mechanism that is built into a private network.

Blockchain Proof of Concept for Helios Energia, a Real Estate Investment Firm

Posted on | by admin

Industry: Financial Services, Real Estate

Overview: Our client was looking to build a proof-of-concept to demonstrate the tokenization of ownership of real estate, and ability to fractionalize said ownership of real property.

Challenge: Helios Energia, a Real Estate Investment Firm was exploring the idea of creating an application that demonstrated the ability to fractionalize ownership of real estate to lower the barrier of entry for investments.

Solutions: Utilize a Blockchain network to tokenize property within a portfolio so ownership can be easily verified, and fractionalized between several parties.

Technologies: Angular, Iconic, Hyperledger Fabric and Composer, Node JS, IBM Cloud Kubernetes container

 

Summary:

Helios Energia, a Real Estate Investment Firm approached TxMQ with an idea to fractionalize property ownership of an investment portfolio to lower the barrier of entry for potential investors. The idea is very similar to crowdfunding a product or service, but also creates an opportunity for real estate ownership for those who may not have the immediate capital or knowledge to invest on their own.

When the Helios team came to TxMQ, immediately it was identified that Blockchain would be a perfect match for their needs. This particular project required the property asset to be digitally tokenized so that ownership could be shared and verified in a secure trustless environment. The ability to tokenize assets is one of the main selling points for Blockchain adoption, and there are many new use cases that have been realized due to this unique feature.

In this case we delivered a Proof-of-Concept that conceptually showed it was possible to tokenize assets on a Blockchain which opened up the opportunity to fractionalize these assets for ownership. TxMQ delivered a Kubernetes containerized application, available on mobile UX interface for ease of management, and visibility.

Screen Shots, and UX examples for Proof of Concept:

Case Study: Middleware Health Check

Posted on | by admin
Project Description

An online invoicing and payment management company (client) requested a WebSphere Systems Health Check to ensure their systems were running optimally and prepared for an expected increase in volume. The project scope called for onsite current state data collection and analysis followed by offsite detailed data analysis and White Paper preparation and delivery. Next, our consultant performed the recommended changed (WebSphere patches and version upgrades).

Click here to learn more about our Middleware Health Check.

The Situation

The client described their systems as “running well” but they were concerned they may have problems as they experienced additional load (700% estimated); memory consumption was a particular concern. TxMQ completed the Health Check and worked with representatives from the client for access to production Linux boxes, web servers, application servers, portal servers, database servers and LDAP servers. Additional client representatives would be available for application-specific questions.

The Response

Monitoring of the components had to be completed during a normal production day. The web servers, application servers, database server, directory server and Tomcat server all needed to be monitored for several hours. The normal production day typically showed a low volume of transactions so the when the monitoring statistics began they were all very normal; resource usage on the boxes was very low. Log files were extracted from the web servers, directory server, database server, deployment manager, application servers and Tomcat (batch) server. Verbose garbage collection was enabled for one of the application servers for analysis and a Javacore and Heap Dump was generated on an application server to analyze threads and find potential memory leaks.

Monitoring and analysis tool options were discussed with the client. TxMQ recommended additional IBM tools and gave a tutorial on the WebSphere Performance Viewer (built into the WebSphere Admin Console). In addition, TxMQ’s consultant sent members of the client’s development team links to download IBM’s Heap Analyzer and Log Analyzer (very useful for analyzing WAS System Logs and Heap Dumps). TxMQ’s consultants met with the client’s development and QA staff to debrief them on the data gathered.

The Results

Overall, the architecture was sound and running well but the WebSphere software had not been patched for several years and code-related errors filled the system logs. There were many potential memory leaks which could have caused serious response and stability problems as the application scales for more users.

The QA team ran stress tests which indicated that the response times would get worse very quickly as more users were added. Further, the version of software and web server plugin was 6.1.0 and vulnerable to many security risks.

The HTTP access and error logs had no unusual or excessive entries. The http_plugin logs were very large and were rotated – making it faster and easier to access the most recent activity.

One of the web servers was using much more memory than the other although it should have been configured exactly the same. The production application servers were monitored over a three-day period and didn’t exhibit any outward signs of stress; the CPU was very low, memory was not maxed out, and the threads & pools were minimally used. There were a few configuration errors and warnings to research but the Admin Console settings were all well within norms.

Items of concern:

1) A large number of application code related errors in the logs; and
2) The memory consumption grows dramatically during the day.

These conditions can be caused by unapplied software patches and code-related issues. In a 24-hour period, Portal node 3 experienced 66 errors and 227 warnings in the SystemOut log and 1396 errors in the SystemErr log. These errors take system resources to process, will cause unpredictable application behavior, and can cause hung threads and memory leaks. The production database server was not stressed – it has plenty of available CPU, memory and disk space. The DB2 diagnostic log had recorded around 4536 errors and 17,854 warnings in the previous few months. The Tivoli Directory server was not stressed – plenty of available CPU, memory and disk space. The SystemOut log recorded 107 errors and 8 warnings in the previous year -­ many of these could be fixed by applying the latest Tivoli Directory Server patch (6.1.0.53). The Batch Job (Tomcat) server was not stressed – plenty of available CPU, memory and disk space. The catalina.out log file is 64Mb and contained many errors and warnings.

The HealthCheck written analysis was delivered to the client with recommended patches and application classes to investigate for errors and memory leaks. In addition, a long-­term plan was outlined to upgrade to a newer version of WebSphere Application Server and migrate off WebSphere Portal Server (since its features were not needed).

Photo courtesy of Flickr contributor Tristan Schmurr