Healthcare Regulatory Compliance Services

— Adopting new regulatory standards in the US Healthcare Industry

The purpose of this paper is to provide a clear understanding of HIPAA and ICD migration, analyze the benefits beyond ICD remediation by providing regulation insights, and discuss the impact of the new regulations on systems, processes, payers, providers, pharmacies, laboratories, and Intermediaries, healthcare organizations, and the industry in general. In addition, it provides insight on the implementation in the healthcare ecosystem.

Industry Challenges:

The two major US healthcare regulatory compliance mandates are, HIPAA migration from 4010 to 5010 electronic transaction set and conversion of ICD-9 code set to ICD-10 code set. Implementation of these mandates will impact every core process, system and interface across the industry and will require a major overhaul in healthcare organizations.

The government has stated specific time lines within which migration and replacements have to be completed.

• HIPAA 5010 Compliance is to be completed by January 1, 2012. All electronic claims provided after this date must use Version 5010 and Version 4010 claims will no longer be accepted.
  
• ICD-10 Compliance is to be completed by October 1, 2013. Claims for services provided on or after this date must use ICD-10 codes for medical diagnosis and inpatient procedures.

Migration of ICD 9 to ICD 10 and meeting the compliance deadline of October 2013 will require a significant amount of awareness, planning and preparedness on the part of payers as well as healthcare professionals. Network management, claims re-pricing, and Provider Contracting constitute the biggest concerns for ICD-10 and HIPAA transition. Integration between web-based technology and administrative services to improve consumer experience is another major challenge for ICD-10 and HIPAA transition. The conversion will also largely impact rating, underwriting, and actuarial policies and guidelines in the Healthcare industry.

In order to meet the compliance deadline and increase the success rate of ICD compliance, payers need to work out a strategic approach to manage change and maximize benefits out of investments. The immediate need is to start the effort with an overall governance structure and manage the transition and mitigate the risks.

HIPAA 5010 Migration

The adoption of HIPAA 5010 is imperative to enable ICD-10 implementation. It involves adopting new guidelines for claims, eligibility inquiries, referral authorizations, remittance advices and other transactions. The migration process adopts an updated version of the National Council for Prescription Drug Programs (NCPDP) standard and a standard for Medicaid pharmacy subrogation transactions.

These new HIPAA regulations have various organizational and technical implications in the industry. Healthcare providers, pharmacy benefit managers, doctors and other enterprises operating in the industry are implementing new standards in order to facilitate the interoperability of stakeholder systems and drive efficiencies.

In order to implement HIPAA migration, there are some basic changes that organizations need to make.

Typical Changes for HIPAA Migration—

• Front Matter Changes – the purpose and business rules related to the transaction under consideration needs to be identified. 
• Technical Improvements – facilitation of effective accommodation of the transaction data collected and transmitted, as well as ensuring that the transmitted data is more comprehensible.
• Structural changes – incorporating modifications to the physical data element components of the transactions.

ICD-10 Migration

The US Department of Health and Human Services (HHS) has proposed a regulation that will replace the ICD-9-Clinical Modification code sets (used to report healthcare diagnoses and procedures), with the new advanced and expanded ICD-10 code sets. The challenge that is being currently being addressed is the transition to new ICD-10 coding. It involves a major overhaul of the current coding systems in all Healthcare organizations. Considering the confidentiality of medical records, automation and up gradation of IT systems require immediate attention.

Migration of migrate from ICD-9 to ICD-10 code sets, involves a major system overhaul, leading to the following changes:

• Increased code set from 18000 to ~140000 and
  
• Structural changes for the codes to Alphanumeric from Numeric format
  
• Code size increased from 5 to 7 character length and leading to higher data volume

Typical Changes for ICD-10 Migration

• Increased code sets – accommodation of increased code sets from 18000 to ~140000.
  
• Increased code sizes – increasing the character length from 5 characters to 7 characters to enable higher volumes of data.
  
• Structural changes – incorporating change in codes from numeric to alphanumeric formats

Business Benefits of migration to ICD 10 and HIPAA 5010

The benefits of migrating to advanced regulatory standards of ICD-10 and HIPAA 5010 are:-

• Facilitating interoperability of stakeholder systems and drives efficiencies.
  
• Enhancing usability and effectiveness of transactions such as claims, eligibility inquiries, referral authorizations, remittance advices and other transactions.
  
• Enabling integration of codes of different versions across systems in the industry.
  
• Providing standardization of interoperability guides between systems across the industry.
  
• Increasing protection of personal medical information (PMI) through limiting ways in which information is shared.
  
• Assisting healthcare consumers in purchasing appropriate health insurance coverage.
  
• Enabling easier accessibility of individual records by patients.

GSS' Solution for Code Conversion: GSS Infotech Experience and Expertise

GSS Infotech provides software and services that can be customized and implemented based on your organizational needs for compliance mandates. The Medicode, an e-learning tool by our expert services, helps not only cut down on the time and human resources required for transition to ICD-10, but also ensures accuracy and consistency in code count and conversion. The tool is a powerful web-based solution, designed to guide your experts through the process of translating codes throughout your business systems and processes to help you maintain your financial health.

Shifting Paradigms: A Fresh Approach to Application Security Frameworks

Shifting Paradigms: A Fresh Approach to Application Security Frameworks
The gap between hacker threats and suitable security defenses is widening, faster than ever - Forrester Research, August 2010.

The need for security in IT systems is greater than ever as businesses operate in today’s uncertain environment. This need runs the gamut of all aspects of the IT universe — Applications, Networks, Systems, and Databases, etc. Today’s threat canvas spares no aspect of IT, and things that were taken for granted until recently are now at risk unless steps are taken, and this translates into a need for robust security testing frameworks.

Even though security managers realize the need to keep up with an ever-changing landscape of threat perceptions their efforts are hamstrung by two key reasons: efforts towards superior security are undertaken in isolation, and security testing is largely treated as an afterthought towards the end of the software development lifecycle. Rather than a reactive approach as has been the trend in the past, it would make eminently more sense to incorporate the rigor of the Security Testing methodologies before the threats loom overhead.

The critical link in the chain with organizations are now waking up to is for security testing to be built into the Software Development Life Cycle (SDLC) rather than be a retro-fitted activity that begins once a security threat is detected. Integration of security testing with SDLC provides early visibility to security vulnerabilities and defects. This provides sufficient time to deploy remedial measures. This integration involves tasks right from the Inception state all the way to Transition.

Abuse Cases, Threat Modeling and Risk-based Security Testing are some of the activities that need to come in during the early stages of the SDLC creating an effective security perimeter around the application development exercise. As the lifecycle draws to a conclusion, tasks such as Penetration Testing, and finally a continuous evaluation of extant threats and their mitigation plans need to form a part of the plan from the start. Ongoing analysis and review of threat mitigation should form a part of the cycle.
At GSS we help clients build robust Security Testing Framework and so that they mitigate risks before they become risks. For more information on this, visit us at www.gssinfotech.com

Widen your vision: Experience Exchange 2010 on a virtualized platform

Running Windows exchange 2010 on a virtualized platform (with Hyper-V or VMware ESX) gives you a plethora of availability and recovery options, each providing varying levels of protection and cost.

Zero time invested in upgrade or system downtime:
A good deal of time, energy, and capital is involved in traditional physical environmental upgrades. It also means risk of data loss and extra time required for the recovery process. Virtualizing exchange server helps save substantial amount of time and money in the following ways—
• Planning and implementation time
• Sizing and acquisition of new hardware
• Downtime for system upgrade, which incurs higher costs and risks of data loss

Faster data recovery minus time and data loss:
Data recovery and systematic storage are the two main concerns for IT professionals. Virtualized Exchange environments can help you recover from-
• Planned or unplanned hardware outages
• Hardware degradation
• Application failure or Failover Clusters
Virtualized capability automatically balances workloads and shared storage on a virtual platform helps in keeping incidents of application failures at bay.

High performance mailbox servers:
Running your exchange server 2010 on a virtualized platform gives you the advantage of enormous largest mailbox server which that exceeds physical performance. In addition, you get the following—

• Virtual Machine scalability up by 8 vCPU and 256 GB of memory
• Disk IO scalability increased to more than 350,000 IOPS, enabling VMware ESX to support IO-intensive applications such as Exchange and large Databases
• Network IO increased to 40 Gbps

This also means enhanced architecture and improved features of Microsoft Exchange 2010 and 2007 that significantly reduce the IO requirements as compared to Exchange 2003.

Do more with enhanced exchange infrastructure:
A virtualized platform for windows exchange server 2010 allows you to scale exchange mailboxes on multiple smaller virtual machines to maximize the throughput of the physical server. Windows Exchange server can be scaled out on 8 Virtual Machines, each supporting 2,000 very heavy mailbox users, to support 16,000 users on one 16-core server.

GSS Infotech, which has VMWare as one of its strategic alliances helps you leverage the inherent benefits of a Microsoft® Exchange Server 2010 deployment on VMware vSphere.

For more information on this, log on to www.gssinfotech.com

Ready for Windows Exchange Server 2010

Windows exchange server 2010 with its wide array of new and advanced features, is worth a try. But if you are all set for an official roll-out, you need to consider a few pre-requisites, before you switch to Windows Exchange Server 2010.

Hardware requirements for Exchange Server 2010:
• System requirements: Exchange server 2010 is compatible with x64 architecture-based computer with Intel processor that supports Intel Extended Memory 64 Technology (Intel EM64T). It also runs fine on any AMD processor that supports the AMD64 platform. However, Intel Itanium family IA64 processors are not supported by Exchange Server 2010.
• Operating system requirements: Exchange server 2010 supports Microsoft Windows Server 2008 x64 Standard and Enterprise Edition with Service Pack 2 or Microsoft Windows Server 2008 R2 Standard and Enterprise Edition.

Software requirements for Exchange Server 2010:
ServerManagerCmd commands and the PowerShell commands are two of the most essential requirements for installing Windows Exchange Server 2010. The related download files contain necessary commands for installing Windows (2008 SP2 or 2008 R2) and for each Exchange role.

You must also keep in mind that if ServerManagerCmd command may use different XML files if you are installing windows server 2008 or other servers. It is also necessary to have Exchange media ready when you are installing a role.

If you need to run Exchange 2010 on a virtualization platform, you need to remember that not all roles are supported. The Unified Messaging Server role, for instance is not supported in a virtual environment because of its reliance on time-sensitive, real-time communications. However, Microsoft exchange server 2010 supports some common virtualization platforms like Microsoft Hyper-V R2, VMware’s ESX/vSphere, and Citrix’s XenServer.

Additional requirements for Exchange Server 2010
There are a couple of other requirements that one needs to consider for adopting Windows Exchange Server 2010, such as —
• Memory ― A minimum of 4 gigabytes (GB) of RAM per server with 5 megabytes (MB) of RAM are required for each mailbox.
• Disk space —At least 1.2 GB space on the drive is used for installation. An additional 500 MB of available disk space is recommended if you have plans for installing for Unified Messaging (UM) language pack.
• Available disk space: At least 200 MB of available disk space is required on the system drive.
• File format―Disk partitions need to be formatted as NTFS file systems.
• Monitor―your screen resolution needs to be 800x600 pixels or higher

Once you have ensured that you have met all of the aforementioned requirements, your adoption of windows exchange server 2010 will be smooth and safe.

For more information on this, log on to www.gssinfotech.com

8 Simple Steps for starting HIPAA 5010 migration

It is a known fact that providers, payers, and vendors are running late with their HIPAA 5010 transition , but things may be even worse than it appears. Only 12% of providers, in fact, have formally initiated their HIPAA 5010 conversions, according to HIMSS, and they're facing a deadline prior to the January 1, 2012 compliance mandate.

“A lot of providers look at 5010 as a project to start in 2010,” says Joe Miller, director of e-business at AmeriHealth Mercy Family Companies. But the first deadline, known as Level 1, is to start trading partner testing on January 1, 2011. “Providers are aware of 5010 but focused on the final compliance date. Many won't be ready to meet the Level 1 compliance.”
That's not to say it's too late, as the month of March winds down, but instead that providers will need to get started pretty much immediately to meet the Level 1 deadline, thereby leaving 2011 for external testing.
During a HIMSS Webinar on Wednesday, Betsy Clore, a senior analyst and programmer at Wake Forest University Health Sciences, and Gale Scott, HIPAA transaction compliance administrator at Tampa General Hospital, outlined 8 steps for getting started.

1. Educate yourself
this begins with getting a clearer understanding of HIPAA 4010 transactions to learn more about the changes in 5010, Wake Forest's Clore says. “And don't assume that X12 is just for techies,” she added. The transition also includes business and regulatory processes, clinical data needs, and even marketing.

2. Analyze changes
Clore recommends the implementation guidelines and the X 12 HIPAA Interpretation Portals as starting points. Changes to consider are impacts to business processes and software, billing procedures, and EDI processes. In Wake Forest's case, converting software and EDI technologies enabled them to use new non-HIPAA 5010 features they did not take advantage of before they upgraded.

3. Communicate with your vendors
Tampa General's Scott explains that by January 1, 2011, providers should be ready to start trading partner testing – and that means vendors have to be on board by then. “Make your vendor aware of your requirements,” Clore adds. “Don't assume that others have covered everything.”

4. Communicate with trading partners
This one is critical because even if you are prepared, a non-compliant trading partner can be trouble. Scott says that a CMS unit will be conducting “random audits to make sure you're compliant.” Fines or other penalties have not yet been detailed but, Scott adds,” There’s every indication they're headed that way.” Clore and Scott recommend understanding partners' timetables and the ways in which testing will be conducted.

5. Upgrade and test vendor software internally
this year is the one for internal upgrades and testing. Remember to “ensure that your 4010 transactions still work,” as you move to 5010, Clore says. In some instances, both Clore and Scott say that their systems work with both 4010 and 5010 transactions, but that depends on the vendor.

6. Update your own customizations and edits
Examples include edits requiring subscriber date of birth and sex, which are no longer needed, as well as some alterations that will need to happen post-compliance, such as turning off the pop-up prompt for patient weight for epoetin, Clore notes.

7. Use a validation service
If you don't already, Clore recommends tapping a validation service to confirm that your transactions are compliant with implementation guidelines. Some services, Clore adds, also handle business edits.

8. Test with trading partners as part of a phased migration
Scott describes the phased migration as “targeted testing of transactions within a full production environment with a gradual transition to full production with one high-volume payer at a time.” Clore says that Wake Forest plans to use just that approach.

For more information on this, please visit our site www.gssinfotech.com