Not every application you want to interface to will use the same transport protocol. Some use TCP, while others may use MLLP, SMTP, FTP, or even a different version of the protocol you have standardized on.

When partners that you have built application interfaces to update or change their transport protocol, your team will need to update the interface on your end.

Where this becomes an issue is managing all the various application interfaces that you connect to. In order to simplify the management of each of the possible application transport protocols that are used, CloudPrime does the conversion for you, allowing you to implement the protocol that your applications speak.

Take for example a trading partner that uses MLLP to stream HL7 messages to the connector interface for transport. The partner configures the interface, sets the correct port and IP address, and the stream connects. On the other side, you can use the configuration of your choice to receive the messages, e.g. simple file transfer or TCP. When the message arrives, CloudPrime will do the conversion, and deliver the messages to your application in the transport protocol specified.

Since CloudPrime is handling the conversion, trading partners will not be effected if one partner moves or upgrades to a newer standard. [See Figure 1] 

 

Figure 1 – Application interfaces using native transport protocols on the CloudPrime network.

CloudPrime currently supports over a dozen transport and message protocols, including TCP, MLLP, EDI, FTP, SFT, and more…

To learn more, contact us at

You have a new application, vendor or hospital that you need to interface to. Everyone in meeting grumbles about how the application interface will be built, where the resources will come from, and who’s budget will take the hit for adding the new partner.

To get started, you start thinking about everything that will need to happen:

1. A new VPN connection will need to be created to bring the new trading partner onto the network… paperwork with the hosting company or telco, network configuration changes, firewall ports opened, etc.

2. Depending on the application or partner you are working with, you need to understand what interfaces you will need support/build, e.g. does the application have a specific transport protocol you are not familiar with, is there a specific message protocol that you will need to convert

3. Specialist that have worked with these types of interfaces will need to be selected and contracted

4. Depending on how many connections you are creating, you may need to bring on additional staff to manage and support these connections

5. If any value added services such as guaranteed delivery or file tracking need to be implemented, this will increase the scope of contract work

6. Each connection will need to be tested thoroughly

VPNs provide the basic necessity of secure connectivity, but they are a unwieldy solution for IT organizations that are faced with deploying many connections and are limited on technical resources, time, and money.

When working with new trading partners, healthcare application interfaces, or vendors, VPNs may not make the most sense for your needs. Think about some of the problems you may face when adding new VPNs and how you can mitigate those pain points:

1. Are there other secure, application connectivity solutions available? If so, do they offer the most basic needs for interoperability?

2. Does the VPN solution offer file-level tracking, encryption, guaranteed delivery and web portals to view message and data traffic?

3. Are there solutions available that do not require changes to the firewall and/or network

4. Is there a solution that will require minimal IT support, reducing the total cost of ownership for maintaining secure outbound connections?

5. Will these connections continue to meet changing government standards for connectivity or will additional work need to be done to keep them compliant?

6. Is there a solution available that does not take weeks or months to implement?

There are many more questions to be answered, but the basic question is “can you find a better way?”. As technology advances and the Cloud becomes a more trusted platform for offering services, it may be time to start seriously evaluating alternatives to VPNs.

2011 is going to see a dramatic increase in the adoption of EHR software and digital patient information exchange will become an even greater priority in order to meet Stage 1 meaningful use requirements.

If you are an IT Manager, this looks like it will require an all hands on deck and a huge shift in how things have been run throughout your organization. Since all patient data will need to be exchanged digitally in a safe and reliable way, you will be tasked with:

• Ensuring application interfaces can connect internally as well as make connections outbound through your firewall
• Making sure your IT ecosystems are documented carefully to determine where the holes are in internal and outbound connectivity
• Allocating resources for managing all new connections and configuring your firewall to accept new connections
• Dedicating staff to managing the new network; either adding to overhead or detracting from other initiatives within the organization

Some things to think about in 2011 as you prepare to meet these new requirements are:

1. Meaningful Use Incentives: Registration for the EHR Incentive program started on January 3rd: http://www.healthcareitnews.com/news/government-ehr-incentive-program-ready-go

2. New Infrastructure: New processes will need to be learned as you begin interfacing to all the EHRs, PMS’, HIEs, Physician Groups, Clinical Labs, etc. being brought onto the network.

3. Security: All patient health information will need to be encrypted and transported securely in order to meet HIPAA compliance.

4. Training: Staff will need to be trained and allocated to manage these networks. As your network continues to grow, so will the resources required to support and manage it. Changes in your firewall will need to happen and application interfaces will need to be built.

5. Solution Providers: HISPs (Health Information Service Providers) will need to be selected. Not everything can/should be done in-house, so you will need to determine how to minimize the total impact of these new application interoperability requirements. Your EMR may already provide application interfaces, but it is possible that many of your systems do not support outbound connectivity.

2011 will bring a lot of change for the healthcare industry as a whole, and with that change, progress. Despite the huge burden these new regulations will have on IT departments large and small, the end game will produce a cohesive, secure and reliable patient information exchange that improves the quality of care for all Americans.

Looking through some of the recent announcements on the Direct Project, it is not completely clear what NHIN is trying to represent if you are an EMR, Health Care Professional or Health Information Service Professional (HISP).

NHIN’s Direct Project is providing a specification and guidance on how interfaces can be built to exchange information in a secure, encrypted way using “email like” addresses on a network.

This is great! This is not an implementation though.

Health care professionals or ISVs who are looking at the Direct Project to solve their connectivity problems will need to understand that an interface will still need to be built, and encryption and key management will still need to be licensed in order to ensure all data is securely sent and in compliance.

This is a great step forward, and standards help drive adoption and innovation, so we will be excited to see how the trials turn out.

NHIN and NHIN Direct (now called “The Direct Project:) are frameworks for creating a standard system through which health care applications can communicate, share information, and connect with one another. And, according to Shahid Shah, in his article titled An Overview of NHIN and NHIN Direct for Software Developers*, “NHIN is far from settled and is not a forgone conclusion for data exchange, so you shouldn’t rest your complete integration strategy on it. In fact, make sure you have other options available to you.”

I don’t want to be too negative on NHIN or those who are striving to make it a production reality, but if you are considering connecting systems leveraging NHIN, you should understand where NHIN stands as a health information exchange solution.

With the HITECH Act, meaningful use (MU), and incentive payments on the line, a lot of organizations are trying to find their health information integrations solutions now, not in the future. As such, below are some weaknesses of NHIN that might be an issue when trying to implement a health care application integration solution:

1. Still in early stages of testing with users

2. Many security policies still need to be defined and implemented by the user

3. Limited documentation for implementation

4. May require application development for exchange integration, making it a resource intense solution to roll out

Given that there are a lot of new compliance regulations to meet in order to receive incentives, IT resources will be stretched, and anywhere you can implement a solution that does not require a large amount of overhead and technical expertise is going to be attractive. Even if NHIN and The Direct Project were ready for prime time, integrating your systems (which could be dozens per location), will require a lot of resources, time, and money.

In short, NHIN is not the silver bullet for health information exchange, nor is it the solution that companies, health care professionals, and application integrators can count on now.

* http://www.ibm.com/developerworks/web/library/wa-nhindirect/index.html

Connecting applications and systems takes time, involves a lot of people and requires training and deployment costs. What if it wasn’t that bad? What if you had an application messaging solution “in a box”? What if that box was a Cloud that allowed you to scale quickly and reduce costs?

Sounds great and it is!

That is what we have been working on here at CloudPrime and we are proud of the best service that allows you to connect disparate software applications on and off your network in an easy to install, scalable, and cost-effective way.

The CloudPrime service provides IT Managers and Administrators with a pre-built application network that resides in the Cloud and enables a network to be established in hours in some cases. Traditionally, if someone wanted to establish a connection between two systems, an IT administrator or manager would have to build a network between the two applications and implement an interface engine in the middle in order to allow the two endpoints to communicate.

Let’s review some of the challenges here:

1. In order to connect two applications on or off the network, personnel needs to be allocated to build those connections,

2. Hardware will need to be deployed to support the connection(s), also requiring more person hours to deploy, maintain and update,

3. Connections are rigid, allowing for only point-to-point communication,

4. In order to implement any value added services, either a 3rd party application provider will need to be brought in, or a RYO (Roll Your Own) solution will need to be built. Either way, this will require more support and more costs,

5. If the systems do not reside on the same network, it will be difficult to get trading partners to accept connections coming into their network for all the reasons above.

Let’s see how CloudPrime provides an easy-to-deploy solution to solve this problem:

1. CloudPrime is a service so no person hours will be need to be contributed to support the network,

2. As a service, there is no hardware for the end-user to purchase or support,

3. CloudPrime provides a small software client that interfaces to applications, encrypts messages and routes them through the appropriate channels,

4. CloudPrime’s service allows disparate applications to communicate without the need for an interface engine,

5. CloudPrime provides file-level tracking, guaranteed delivery, and a variety of other built-in value added services, enabling IT managers to meet compliance and avoid customization costs,

6. CloudPrime provides reporting tools to increase management’s visibility into application network performance and costs,

7. Since CloudPrime is easy to install, bringing up trading partners on and off your network is easy and can be done in as little as 20 minutes,

8. CloudPrime leverages the Cloud to scale with usage and provides users a cost-effective, pay-as-you-grow pricing model.

Discover how your organization can build meaningful application interfaces with CloudPrime by doing a trial of the product free for 30-Days!

Sales:

CloudPrime Sales

1400 Fashion Island Blvd., Suite 400

San Mateo, CA 94404

In this article I wanted to review how one could create a Health Information Exchange using CloudPrime. What this means in the most simple terms is that the CloudPrime application messaging network enables you to connect health care application endpoints to a central hub for the purpose of creating an electronic data interchange. This information exchange can send data back to all the constituents as well as connect out to another network outside the system.

Exhibit A below represents the network topography of CloudPrime when implemented in a hub-and-spoke configuration. As you can see, there is a centralized EHR that connects out to various hospitals, physician groups, clinical labs, and pharmacies. Each one of these endpoints communicates in a two-way message exchange back to the central EHR (or HIE, Head Quarters, etc.), encrypting all traffic over the network.

Exhibit A

 

This is achieved by installing what is called a “CP Connector” at each end-point that interfaces to the application that will be sending data. These Connectors are capable of picking up HL7, EDI X12, and Flat Files (to see a full list of Protocols Supported, please visit https://cloudprime.net) and passing them along to the destination connectors via the Cloud. What is important to note is how the messages travel over the network.

1. The messages are picked up and encrypted behind the endpoint’s firewall, ensuring all messages are sent securely,
2. Messages are sent over multiple paths to guarantee the arrival of each message, something we call Multi-Pathing,
3. Store and forward: A copy of each message is stored in the online data stores (in the Cloud) and persist until the message is delivered. Online storage is rules based, so CIOs and IT Managers can keep messages encrypted in the Cloud for as long as they want,
4. The first message that arrives at the destination will be decrypted and delivered to the appropriate file system directory or application interface. The connector automatically de-duplicates each message and destroys any message that arrives after the first.
5. All message transactions can be viewed in the CloudPrime portal for reporting and non-repudiation.

Deploy A Health Information Exchange Quickly

It can take as little as a month to deploy a CloudPrime Health Information Exchange, and once your network is established, adding new endpoints can be done in a matter of minutes.*

Below is a diagram of the simple steps required for downloading and installing a Connector at a new application endpoint.

Elapsed Time of Connector Installation

Once a Connector is installed, the user simply creates a connection (called Channels) interfacing to the source application and specifies the destination address on the CloudPrime network. Once this is done, the user can start sending messages back and forth to their trading partners on the network.

CloudPrime Channel Configuration Screen

CloudPrime makes it easy to create a secure, scalable and cost-effective health information exchange, connecting all the necessary dots on your network to achieve interoperability and compliance. To learn more about how you can begin using CloudPrime today to establish a Health Information Exchange on your network, contact us by emailing sales @ cloudprime dot net or calling .

* This is based on previous customer implementations. Experiences may vary depending on the requirements.

As a company that leverages Cloud infrastructure to provide cost-effective, scalable and secure application messaging services, I get a lot of questions about how we make the Cloud secure. Before I address this question, I figured it would be interesting to first take a look at the history of Cloud computing. I ask forgiveness in advance for all my gross-oversimplifications.

The Early Years

Cloud computing first started being described in the 60′s when the pioneers of ARPANET envisioned that people all of the world could connect and access data from each other over a network. Having an interconnected “web” would provide the foundation for distributed computing. Further, John McCarty, a noted computer scientist, proposed the idea of “computation being delivered as a public utility.” (ComputerWeekly.com, March 2009), much like it is used today.

Through the 80′s, the concept of a client-server model for operating applications and platforms within an enterprise began to take root and lay a foundation for what we recognize as “the Cloud” today. Client-server systems require that one computing appliance, ideally with a great amount of computing power and capacity, would be able to serve multiple clients (PC’s, terminals, etc.) around the world. One famous example of this in the 80′s was BITNET which connected IBM mainframes in order to send electronic mail to academic institutions around the world. (A brief history of the internet, Internet Society, 2010)

Emergence of Cloud Computing

Although the idea of a “Cloud” infrastructure was seeded in the 1960′s, it was not really until the 1990′s that we saw any semblance of Cloud computing the way we know it today. In the late 90′s, SalesForce pioneered one of the first SaaS (software as a service) CRM applications and boldly labeled their innovated business model as “The end of software” since you did not have to purchase and install an application locally.

Although it appeared that SaaS based software models would be the future of how we used and interfaced with applications, these applications were still hosted in server farms or locally by the companies that published the software. In 2006, Amazon.com launched a new service that would change how we thought about hosted computing and helped catapult Cloud computing into the spotlight.

Cloud Computing Evolved

Amazon’s EC2 environment gives developers and software publishers a way to access what seems like unlimited resources in a “pay for what you use” model. This combination of low cost and scalable server resources made it possible for developers with very little money to develop applications and publish them (very quickly!) for the community to use. While this was a great milestone for developers and just about anyone who has ever used the internet, many people, businesses, and experts did not believe that the Cloud could provide the security and reliability needed to run enterprise grade applications.

While Amazon provides a paid public service (much like the one anticipated by John McCarthy), many users of the Cloud leverage what is called a “Private Cloud”. This generally means that the host of the distributed computing center has created a cloud environment but its resources are not made publicly available. Bringing the Cloud internally allows managers to have more control over security and maintenance, instead of relying on a provider. Private Clouds help satisfy many of the concerns IT Managers and CIOs have around security while allowing them to take advantage of the benefits of Cloud computing. Eric Knorr of InfoWorld has a great article here discussing “Private Clouds”.

Cloud Computing Today

Today, there is a wide range of options for developers and publishers of software when evaluating which Cloud provider they will use to host their applications. Companies like Microsoft and IBM have started offering services providing their customers with “elastic cloud” environments that promise services that are scalable, easy to access, and inexpensive to use. Seeing more and more large players, as well as small and medium size boutique cloud providers enter the market is a signal that more and more companies are adopting the Cloud as an acceptable infrastructure for hosting their data and applications.

CloudPrime Leverages the Cloud

CloudPrime is a service that leverages* the Cloud for many of the same reasons any other business might. The Cloud provides a scalable, cost-effective and on-demand environment through which we can provide our application messaging services. When people ask how it is that we can leverage the Cloud when it is not secure, the answer is two fold:

1. We only work with Cloud providers that can pass SAS 70 type II compliance, and

2. CloudPrime encrypts all messages over the network, making all data traveling through and stored on the Cloud completely secure

Having an infrastructure that can scale as you grow allows our business to provide a rich and robust service without you incurring large up-front costs or expensive service fees for transferring data between local and hosted applications. You can learn more about CloudPrime and our services by visiting https://cloudprime.net

* CloudPrime uses the Cloud as a component of its service and an overview of the CP Messaging Topography can be seen here: https://cloudprime.net

When most people talk about “The Enterprise”, they are referring to large corporate establishments. We all know it is a fictional craft sailing through the far reaches of space to “boldly go where no person has gone before”.

[You either hate me or love me at this point]

All kidding aside, I recently engaged in a discussion with a friend where they asked if CloudPrime works for “The Enterprise”. I am assuming that he meant corporations in the traditional sense, and when I responded that our customers in the Health Care space are enterprise customers, he looked at me with dismay.

When most people hear “The Enterprise”, they think of supply chain management, financial transactions and CRM tools to name a few. Rarely do I hear people mention Health Care (Health Care Networks, hospitals, physician groups, clinics, state agencies, etc.) when describing who their enterprise customers are.

In large part, I think this is due to the Health Care industry historically being late adopters of technology, and thus viewed as an outsider to The Enterprise discussion. With the recent stimulus funding, passing of the HITECH Act and stricter HIPAA compliance regulations, the Health Care industry is consuming enterprise grade applications and systems on a unparalleled scale and quickly is gaining a lot of attention by business and solution providers who wish to pander their goods to anyone and everyone in Health Care.

Where there can be a parallel drawn is to the late 80s (through today), when businesses began leveraging the Internet to connect to other systems within their trading community or across their organization (think EDI, Lease Lines, VANs, MFT, etc.). The Health Care industry is being challenged by a similar problem in that they are required to connect all systems to the health information exchange to allow for secure digital transmission and ubiquitous access to electronic health records.

While many still do not think of the Health Care industry as an enterprise-class market, it is hard to ignore how much focus companies like GE, IBM, and Intuit are putting into this space, signaling that the major players of enterprise grade solutions have a different perspective on what is and is not “enterprise”.

In the news, more and more reports on Docs using their mobile devices are springing up. This could be good or bad news depending on your attitude towards privacy and your personal health information.

The Good

 It has long been a perception that the health care industry is living in the stone-age when it comes to adopting cutting edge technology and information services in the context of patient services, but with the HITECH Act, HIPAA Compliance regulations, and the pervasiveness of smartphones, this is changing quickly. 94% of docs are now using mobile phones, a 60% increase from a 2006 study performed by the Spyglass Consulting Group in Menlo Park, CA. Having such widespread adoption would lead one to believe that doctors now have the ability to be much more repsonsive to their patients and can get more done. Think again…

The Bad

The same study performed by Spyglass also found that 78% of the doctors in their sample reported issues communicating with their smartphones. This was in large part due to the lack of integration with other services they use (EHRs, Patient Management Systems, proprietary email clients, etc.) and/or the inability to receive mobile reception/services in a particular area or hospital.

While it seems there is more open adoption of technology within the health care industry, it is apparent that there is little convergence and integration occuring between the desktop/web application and the mobile worlds. Obviously, there is a lot of work going into integration between health care application platforms and clients (devices, desktops, etc.), but it is hard to see when true inter-connectivity will actually happen in the context the ONC would like to see it.

The Ugly

It is on your mind: “My information is on a device. That device can be lost or stolen. My information is not secure.” This is true, scary true. Mobile devices and smartphones are amazing utilities, but they also provide one of the scariest security holes for health care CIO’s and compliance officials. If a doctor leaves their device, by accident, in a coffee shop and it is not locked or secured in any way, that information is now public in the mind of a security expert.

According to Veterans Affairs, 37 smart phones were lost in the past two months (June/July) by employees. Smartphones that have thousands of emails on them with sensitive information. Compound these numbers by the number of docs using smartphones and we have a lot of sensitive information floating around.

There are some basic counter measures that help secure devices, e.g. lock-and-wipe, time-outs, password protection, but if we have learned anything about digital security, there is no such thing as total protection.

Another issue with mobile devices and smartphones is their reliability when sending patient data/information. For example, a doctor uses their smartphone to send a prescription to a pharmacy. How do we know it got there? Went to the right pharmacy? Or if it did not get there, where did it go? The reliable transmission of sensitive data over the network when using mobile devices is immature at best, especially when it is clear that inter-connectivity has not been addressed.

Summary

With the widespread adoption of technology in any area, there are always going to be security concerns. As the health care industry moves towards the ubiquitous adoption of mobile devices and the digital exchange of health information, we must realize there will be challenges and not to live in fear of them.

CIOs and Health IT experts will need to look into new solutions to create robust and reliable security policies that cover their network from end-to-end, even the hard to control and manage smartphones.