Archive for February 2013
What does it mean to govern the flow of data?

By Paul French, VP, Strategy, Axway

IT governance isn’t new. It’s been around for years, beginning with the noble goal of aligning IT and business interests. Sure, there were the inevitable “track and monitor our IT spend” and “make sure we protect ourselves” goals, but they were secondary.

Soon, “governance” was a branded term, and infrastructure, reporting, and even complete solution categories were dedicated to governance. And in most cases, aligning IT and business interests was no longer the primary goal, falling a close second behind risk management.

With changing interests came changing measurement and expectations. IT was expected to “lock it down” — to control the experience from access control to data availability. And while this likely removed the perceived risk, it also seriously reduced the business agility the changing environment required. The pendulum had swung too far in the other direction.

So, we tried to have the best of both worlds — control and flexibility. Leading the charge were Service Oriented Architectures (SOA), a new way that promised increased availability, re-use, control, and a modified definition of governance. More inclusive than the “risk management is job #1″ criteria of old, this new governance model promised all the control but with a reduced risk profile. Nirvana was upon us.

Except it wasn’t. Quickly we recognized a limit to what we can control. Humans, trading partners, complex business processes — these didn’t fall neatly into the realm of SOA governance. We were close, but not quite there. What we missed in the process was the difference between governance and governing.

Quite simply, governance is establishing the rules, trusting the participants to follow them, and closing the loop on how well they behaved. Governing is taking those same rules and having continuous involvement in the process.

Let’s consider an analogy.

A parent forbidding their child from eating cookies before dinner is a form of governance over the child’s diet. In this case, the parent is counting on the child to behave according to the guidelines the parent established.

By dinner time, the parent will know if the child followed the process. Does the child eat their dinner? Do they have cookie crumbs on their shirt? Are there cookies missing from the jar?

The parent set out a clear process, hoped it was followed, and was limited to some data analysis at the end of the process. Did they get the results they expected?

Governing takes a more proactive approach. The parent still needs to establish the rules from the outset. They still need to analyze the data at the end to ensure compliance and provide opportunities for continuous improvement. But governing accounts for the control of the flows as they move through the process.

To follow up with our child — now there are guidelines as before, but there are also guide rails to help deliver the desired results. Want a cookie? Here’s an apple instead!

Governing takes the promise of IT governance one step further. It includes the design of the expectations and desired results, connects the participants (whether they are systems, applications, trading partners, etc.) to the process, controls the flow of data to guarantee the defined goals are achieved, and closes the loop with analysis. Governing is the action that delivers on the goals of governance. It includes the parameters to work within, the connection of the participants in the flows, and the analysis of the flows against the expectations.

It also includes that step previously absent in the middle: control.

Control is governing’s secret sauce. It makes the rules reality, engages the participants in a way that matches their workflow (e.g., human or system, real-time or batch, mobile or desktop?), and aligns directly with the expectations established.

Governance is (mostly) passive. Governing is active. You’ve long embraced the former, but now’s the time to embrace the latter. It’s not enough to insist upon a set of behaviors, outline the consequences of failures to comply, and oblige users to sign agreements they surely haven’t read. You must make compliance effortless. You must make it more attractive than non-compliance. You must make it all but impossible for your users to disappoint you.

If you don’t, and they do, will you — knowing what you know now — be satisfied that you did everything you could to help them succeed?

5 Steps to Securing Devices and Services in Healthcare IT

By Ed King, Vice President of Product Marketing, Axway

Today’s healthcare IT organizations know they can’t simply forbid healthcare providers from taking advantage of mobile devices like iPads and cloud-computing services like Dropbox. If a doctor wants to use his Galaxy Tab 4G to share clinical research data with a colleague via a cellular connection and Google Drive, he can.

Nevertheless, there are five steps healthcare IT organizations can take to prevent security breaches and ensure their organization stays HIPAA compliant.

1. Publish your guidelines and a list of approved, recommended services

When healthcare providers use unsecured, non-compliant devices and services, it’s usually because they A) don’t know the risks and B) don’t know which services are the most secure and compliant. Be sure your organization publishes cloud and mobile usage guidelines, educates users on risks associated with cloud and mobile computing, and provides a list of recommended cloud services.

2. Keep it simple and make it effortless for your users to comply

Approved or not, hard-to-use devices and services will be shunned by your users. Choose devices and services known for their quality user experience. Enhance these recommended services with single sign-on and pre-built enterprise integration to further encourage adoption.

3. Control user access

Your users will access the same data and applications from their smartphone, tablet, and laptop, which will make it difficult for you to control access to sensitive data and applications. Upgrade your identity and access management platforms to support a mobile workforce. Incorporate device identity, application identity, and network context into an extended, risk-based, enterprise access-control scheme.

4. Monitor data flows and be ready to redact

To ensure security and compliance, you need to control the amount of data delivered to users and devices. However, legacy backend systems typically lack adequate role or context-based access control, so you should use cloud and mobile-gateway technologies to monitor and redact (i.e., remove, mask, or encrypt) sensitive data whenever necessary.

5. Minimize data persistence

Mobile devices are less secure than computers because A) they have relatively lightweight security infrastructures, and B) they’re easily lost or stolen. Persistent sensitive data on mobile devices is therefore a security and compliance risk, but the risk can be minimized when mobile applications access data dynamically and don’t rely on local data storage. To ensure that mobile applications are designed properly, be sure to establish architectural guidelines and educate your developers on security best practices. To ensure that just the right amount of data is accessible when needed, equip backend systems with the appropriate mobile/Web-compatible APIs. You’ll be able to deliver data on demand and you’ll reduce data persistence.

The days of healthcare IT organizations ruling over devices and services may be over, but the era of prudent, preventive IT care is well underway. Healthcare organizations that heed the five steps above can rest assured that their actions will minimize their security and compliance risks, while those who opt for a more traditional route — filled with demands that fall on deaf ears, rationales that are never respected, and martial policies that no one appreciates — tempt fate.

Which path will your organization take?

 

Learn more about the #HIMSS13 Blog Carnival, a week-long series that highlights guest posts from a variety of health IT authors that center on the most pressing issues that will be discussed at HIMSS13.