Perficient Healtchare Solutions Blog

Subscribe via Email

Subscribe to RSS feed

Archives

Posts Tagged ‘hipaa’

Top 5 Technology Trends in Healthcare – October 2013

The healthcare IT field is rapidly developing and changing. Emerging technology and updated regulations put pressure on healthcare providers and health plans to stay ahead of the curve. Perficient creates a monthly list that explores some of the current topics and issues in health IT. This list examines the most talked about issues and technologies that are currently affecting the industry.

 HCBlog Top5 Trends

Mobile Medical Applications

Last month, the FDA released its final guidance for developers of mobile medical applications. The FDA will focus on regulating potentially harmful apps instead of policing applications that pose minimal risk to consumers. These more harmful apps include those which are using mobile technology to make a specific diagnosis and those which transform mobile devices into a regulated medical device.

Patient Engagement and Connected Health

With the progression of patient engagement, consumers are looking to become involved in their own care and health. The quantified-self movement helps patients track their health, physical activity, food consumption, heart rate, and more. From mobile apps to worn digital sensors like the FitBit to implanted devices, patients keep track of their own health data – which eventually may be used to create a more personalized experience.

Read the rest of this post »

HIPAA and its Impact on Your Organization

I bet many of you have heard of HIPAA, but you may not realize its impact on you and your organization.  Personally, if you or a family member has been to see a physician in the last 10 year, you were presented with a HIPAA form to sign.  Professionally, if you work in healthcare, you surely have heard of it and hopefully have been through awareness training.  Even though there’s a training course in place, that doesn’t mean your organization is fully compliant.  For those of you that work for a third party that provides services to a healthcare organization, the potential impact to your organization is even more urgent.  So please read on.

The basic types of healthcare entities in the market are payers, or health plans, and providers.  Payers are organizations that offer health insurance, either through their own health plans or working with employers to support the employer in offering an employer-sponsored health plan.  More than 50% of the people in the US participate in an locked-computer-keyboardemployer sponsored plan.  As for the remaining Americans, 16% are covered by Medicare, 17% by Medicaid and the remaining 15% are uninsured.  I’m sure you’ve seen the news lately about the opening of the Health Insurance Exchanges, or HIXs.  Initially, the HIXs are targeting those that didn’t have insurance, either because the individual didn’t work for an employer that offered health coverage or due to cost.  Healthcare reform has made changes to ensure that everyone can obtain coverage and do so affordably, either through an HIX or your employer.

The term provider refers to all who deliver health care services to you and your family.  A provider can be your family doctor, local hospital or MRI facility.  Providers deliver health care services to you and, if you have insurance, interact with the insurance company to determine what your health plan will pay and what you as a patient are required to pay, such as a deductible and copay.

Read the rest of this post »

Beauty Is In the Portal of the Beholder…Or Is It?

I was intrigued to review the entries for the New York eHealth Collaborative Portal Contest. Why would a physician be interested in patient portal design anyway? There are numerous reasons. First of all, I am fascinated by smart, eye-catching designs. Secondly, I believe that usability is directly related to design and this could significantly further patient engagement, help satisfy Meaningful Use requirements and create a usable personal health record (PHR) for patients as mentioned in my previous blog. So which design will win?

One of the competitors, CEO Christopher Bradley of Mana Health, believes that image based design plays a key role in creating an intuitive, patient centered experience. They have even begun to incorporate patient entered, device entered data (from Fit Bit, for example). This could be a game changer for many patients who want to track their daily fitness and exercise and have it mesh with their PHR. It doesn’t stop here, though. Could we then use predictive analytics to determine whether our activities are actually helping improve our health AND deliver that information to the portal through a series of easy to use icons? I think we can.

There are some drawbacks, however. As Dr. John Halamka, Healthcare CIO of Beth Israel Deaconess Hospital, so elegantly stated in the Wall Street Journal, privacy can be of concern. Our Healthcare IT system is still in its infancy and therefore, we have had difficulty parsing out protected health information (PHI) that many patients do not want to share with others, a process called data segmentation. We may be able to graphically capture, collate, trend, predict and make all of the information usable….but at what expense?

So can we create a beautiful, patient friendly, HIPAA compliant portal that really delivers insight and value to patients? I am curious to see who wins this battle in New York. Whoever can combine simplicity, beauty and ease of use with backend integrity will certainly have my vote!

Are you ready for the Mandated (ACA) Healthcare Operating Rules?

The 2010 passage of the Patient Protection and Affordable Care Act (ACA) and its Section 1104 establishes a national healthcare operating rule mandate in support of the industry’s ongoing administrative simplification efforts. The first healthcare operating rule set, issued by CMS in July 2011, mandates the adoption of CAQH CORE Operating Rules for Eligibility and Claim Status transactions. This mandate applies to all HIPAA covered entities and is effective January 1, 2013.  Subsequently, on January 1, 2014, operating rule regulations will become effective for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) transactions.

What is a HIPAA covered entity?  A HIPAA covered entity is any organization or corporation that directly handles Personal Health Information (PHI) or Personal Health Records (PHR). The most common examples of covered entities include hospitals, doctors’ offices and health insurance providers.

If you haven’t started yet, better get a move on.  There is quite a bit of information to sift through, and you need to determine if you are compliant.  The best source of information for these rules is the CAQH CORE Phase I and Phase II documents which can be found on the CAQH website http://www.caqh.org/.  You don’t have to get the certification, but the documentation found on this site is extremely helpful in determining your compliancy.

The transaction sets that need to be compliant by the end of this year are the 270/271 and 276/277.  Other items covered that must be compliant by the end of the year: mandated times your systems must be available for receiving and sending, “safe harbor” connectivity requirements, normalizing patient last name, “standardized” companion guides, and response times.

Let’s start with the transaction sets.  The biggest changes here are to the EB (CAQH Phase I CORE 154 rule and Phase II CORE 260 rule) and AAA (CAQH Phase II CORE 259 rule) segments.  Review these carefully as there are very explicit rules as to what data should be sent and when.

Next big one is the ruling on connectivity (CAQH Phase I CORE rule 153, 155, 156, 157, CAQH Phase II CORE rule 250, 270), system availability (CAQH Phase I CORE rule 157 and Phase II CORE rule 250), and companion guides (CAQH Phase I CORE rule 152).  Once again there are very explicit rules on each of these subjects.

Hopefully everyone is already working on this compliancy and have it well in hand.  Don’t be dismayed, it’s really not as bad as it looks!

Choosing a Clearinghouse/VAN

Choosing your clearinghouse or VAN is a very important step, especially if you are in healthcare.  In healthcare you need to make sure they are HIPAA compliant, which means they will be able to handle all the mandated transaction sets.  Other industries have different requirements.  Whichever clearinghouse you choose, you need to make sure they can handle all the transaction sets you might want to utilize.

When shopping for your clearinghouse or VAN, make a check list of your requirements.  Here are a few of the most common questions you’ll want to address in creating your list:

  1. What transaction sets can they handle?  In healthcare, some of the transaction sets would be 834, 837, 835, 270/271, 276/277, etc.
  2. What is the problem resolution process?  Who do you contact?  How is the issue resolved?  If there is a programming change how long does it take for the change to be effective?
  3. How is data transmitted?  Is this done via web connection, SFTP, FTP, etc?
  4. How often is data transmitted?  Is data transmitted real time, batch, once daily, etc?
  5. What is the cost per transaction set?  Is the charge per ISA, transaction set, or bytes?
  6. What is the initial set up fee?
  7. What is the contract period?
  8. What additional expenses are required?  Do you need additional hardware, software, programming, etc. to trade data with the clearinghouse?

It is a good idea to have at least 2 different proposals put together.  Best case and acceptable scenarios, with justification for each.  This will give management a good idea of why you are proposing a particular clearinghouse/VAN.

Once you have gathered all the information you can put together the proposed budget for this implementation.

Whether this is an implementation of its own or part of a larger implementation, keep in mind to get all affected parties involved.  This will help eliminate issues further down the road.

Are there any additional questions you would consider for your requirements list?

Creating your EDI mapping layout

In the previous blog we discussed the importance of knowing your data and business requirement needs. This is one place where that becomes important. If you already know your needs it makes it much easier to start your data mapping.

First you should contact your trading partner. They should have some type of functional specs which state what they expect to send to you or receive from you  or these are specs they will request from you.

Let’s begin with the layout of the transaction set for outbound data. I have found that the best way to start is to take the segments of the transaction set and put them in an Excel spreadsheet, keeping in mind to maintain the segment looping structures. Once you have the segments in your document you can then flesh them out further by putting in the individual data elements and sub-elements for that segment. As you are doing this it would be a good idea to mark each data element as to whether or not they are required, optional or situational. This will help you determine what needs to be present when creating the final product.

Now that you have the transaction set laid out in an editable format you can start marking those fields that fit the identified business needs. You can now use this document to cross reference to your trading partners’ specs as well. Keep in mind that if the data element states it is a required field you must have it populated with data.

Once this layout is complete it is time to start cross mapping to your database. Chances are you will be mapping to numerous tables based on the database layouts where each business unit utilizes their particular data, etc. These should all be reflected in your document and you should be working with your database administrator to make sure everything is being placed into or pulled from the proper table and field as well as whether or not any additional fields will need to be added to the database tables.

Now that you have your document complete you should review once again with the vested parties to make sure everything is as expected. This is a good time to identify any additional requirements or changes that need to be made before you start the actual mapping process.

You are now ready to start working with the mappers to create the transaction set.

The Importance of Being Earnest about Security in Healthcare, Part 2

First, let me start with questions I asked at the close of Part 1.  How does your organization manage security and its risks?  Do you have a governance process in place, is it comprehensive, requirements driven, with the risks communicated, understood and mitigation plans developed and reviewed?  Can you adequately answer these questions?  If you can’t, please read on.  I’ll provide my thoughts and an approach to help you to answer them.

Establish a Baseline

Before you can begin improving and better managing your organization’s security, you must first understand where you are today.  Establishing a baseline enables you to compare your organization to industry standards, regulations and best practices.  It can be difficult to find documented best practices and standards.  In my efforts, I’ve found the work done by and for the federal government to be a good source, particularly in the case of healthcare.

Lay the Groundwork

For security to be effective, it must become part of your organization’s culture.  For many, this is still seen as the domain of IT, yet when you review the HIPAA Security Rule, compliance with the safeguards clearly requires the involvement of many from across your company.  To get started, you need to create awareness at the top.  I’ve found using actual occurrences as examples, such as the one I referred to in Part 1, good teaching aids.  When senior execs understand the size of the potential unplanned expenditures and fines, as well as unwelcomed notoriety, they are much more willing to take notice and action.  In seeking assistance with this educational process, I’ve found the legal, privacy and compliance folks a great help.

In conjunction with the awareness campaign, roll out a governance process led by the establishment of a steering committee comprised of key senior execs.  Make sure to provide them with a basic understanding of security, on-going expenditures to maintain the current state, planned expenditures and with known risks.  Known risks should be quantified, evaluated and have mitigation plans for those with the most exposure.  This enables the committee to better relate to, evaluate, prioritize and manage/accept the risks.  If you are unsure as to the risks and/or have not done a security assessment before, this is a great time to do your first one.

Best Practices

An initial assessment can take four to six weeks as there is a great deal of information gathering required to answer the many questions.  I would suggest using a third-party as they can bring objectivity and won’t be encumbered by any organizational biases.  Ideally the resource should be certified, such as a CISSP.  As to detail of the assessment, that depends on the maturity of your governance and experience conducting assessments.  Typically, confirming/understanding where you are, if there gaps between that and your benchmarks, what the costs are to fill the gaps and what your risk exposure is.  To not bite off too much at once I recommend a progressive approach.  Initially, focus on the HIPAA Administrative, Technical and Physical Safeguards.  You can use them as a benchmark and questionnaire.  As your confidence and compliance grows include the SANS Institutes 20 Critical Security Controls in the next or a future assessment.  They are an amalgamation of a number of the critical NIST SP 800-53, Rev 3, Controls.  Lastly, when you’re ready to take a leadership position in security, focus on the entire set of controls as presented in the NIST SP 800-53, current rev, Recommend Security Controls document.  It can take many years and assessment loops to get to the greatest detail.

Conduct the Assessment

A time limit should be set for each assessment.  The assessment itself should ideally involve your staff researching and answering the specific set of questions in concert with the third party.  They know where to get the detail and it will help that all is fresh in their mind when reviewing the results.  At the completion of the assessment, the third party will consolidate and review the findings, identifying the gaps and presenting their report.  You and your staff will then need to evaluate the risks and develop mitigation plans.  The risks should be prioritized, with the cost and effort to mitigate each defined.  The completed findings would be presented to the steering committee for review and a decision on which risks are acceptable and which must be remediated.  Remediation work would then proceed based upon the prioritization and exposure of the risk.

Ongoing

To keep from inadvertently introducing risk as change occurs, it is prudent to include a step to conduct a gap/impact analysis against your security baseline in any project that will result in changes being made to your organizations technology environment.  Establishing good security governance and practice can be straight forward.  There’s really no special recipe, with the approach being similar to and a subset of other technology governance practices.  Communication and awareness are paramount.  Nothing is perfect and technology is always in motion.  It’s critical that senior management understands the risks, potential outcomes and mitigation costs in order to manage your company’s exposure.

You’ll find links below for those items I’ve referenced above, along with some other items of interest.

The Importance of Being Earnest about Security in Healthcare, Part 1

In Healthcare, we talk about how important security is, all the while secretly hoping and assuming that, as an organization, we’re in compliance and have all the appropriate safeguards in place.  When discussing compliance, at the very least this refers to the baseline set by the HIPAA Security Rule and the many contractual obligations we have, including Business Associate Agreements (BAA), being a Covered Entity and confidentiality clauses.

Typically, the way security has evolved and grown up in organizations has been piecemeal and bottom-up.  As we deployed new components of our infrastructure, we would integrate them into the environment, adopting it to the standard the individuals doing the deployment understood.  We assumed this approach would ensure the continued safety and protection of our data, intellectual property and other assets.  The challenge with this approach is two-fold.  It assumes the existence of both an enterprise security plan, which all know and understand, and a process by which we periodically review our company’s environment for adherence to that plan.  To further complicate matters, the enterprise security plan should be based upon business, legal and regulatory requirements, published and generally accepted best practices and accepted risk.  The latter refers to management conversations that compare the cost of doing something and the potential future cost of not doing it and dealing with the issue if it arises.

To further illustrate the last point, with the enactment of the HITECH act and clarification of many things relating to both privacy and security, risk management has taken on a greater importance and should be a topic of interest for senior executives.  As an example, there was a recent article about a New England firm which experienced a breach.  An employee’s laptop was stolen from their car.  The laptop in question contained PHI.  The firm ended spending upwards of $300,000 in fees and hundreds of hours of staff time to address the breach.  If one breach is $300,000 plus staff time, how does that compare to the cost of encrypting and monitoring all devices that exist off-premise?

My question to you is how does your organization manage Security and its risks?  Do you have a governance process in place, is it comprehensive, requirements driven, with the risks communicated, understood and mitigation plans developed and reviewed?

In Part 2 of this blog, I’ll provide ideas and suggestions on how to improve the management and governance of Security, allowing it to come out of the closet and become better appreciated, understood and accepted by all.  A well governed and managed Security Plan can become an asset and differentiator when competing for new business, as well as retaining existing.

Will you protect PHI or Leave Patients Naked to the World?

Intimate medical details about your health is no longer stored safely in a dusty locked file cabinet.  Thanks to the HITECH Act of 2009, your private health information will end up in data files that hundreds of healthcare workers may have the ability to access.  However, in early 2003 the Department of Health and Human Services (DHHS) issued the HIPAA Privacy Rule, which sets a national standard for healthcare privacy in the electronic age.

The HIPAA Privacy Rule has strengthened patient’s rights substantially, but also keep the monetary burden of accountability restricted to government digression by denying patients a “private right of action.” In other words, patients have no authority to file a lawsuit against providers or payers for violations of the Privacy Rule.  A patient only has the right to file a complaint.  This containment of accountability paved the way for today’s numerous healthcare privacy breaches.

Since punishment for privacy breaches is limited, security has fallen off the radar in many organizations. A Ponemon study confirms that security breaches increased by 35% (year-on-year) in 2011.  Despite the estimated $4-8 billion price tag associated with healthcare data breaches, many healthcare organizations are doing little to protect PHI.  Instead of investing in protecting PHI, Ponemon points out that many “healthcare organizations – especially not-for-profit hospitals and small clinics – have thin margins … and are lacking sufficient security and privacy budgets needed to adequately protect patients.”

It appears that the healthcare industry and federal regulation has reached an impasse.  The federal government needs to determine if its time to better define and strengthen penalties for organizations that fail to protect PHI or if patient’s should have the right to legally pursue organizations that fail to protect their information.   Either way, thanks to the many changes the industry is experiencing, confidentiality is creeping in to the picture. Organizations must resolve to give confidentiality the attention it deserves.

Want to learn more about this topic? Join our webinar “How to Protect Patient Data in an Increasingly Social Healthcare Industry” on January 26th. Details and registration can be found at https://www2.gotomeeting.com/register/483961682. Register for the webinar and you will be entered to win a Perficient client badge to the February HIMSS conference in Las Vegas!

Were you ready for HIPAA 5010?

Hopefully everyone answered ‘yes’ and you had a smooth transition.  In this blog we will discuss some of the items we need to keep in mind when either transitioning or implementing EDI.

Whether you are getting ready to transition to a new standard or initiating EDI for the first time, remember the most important thing is to KNOW YOUR DATA NEEDS!

Knowing what data you expect to send and receive is one of the most important items you can establish.

First, review the standard for the transaction set(s) you want to use (some of the transaction sets used for healthcare are 835, 834 837, 270/271, etc).  Whether this is for Healthcare, Automotive, or any other standard, this is very important.  This will give you an idea of what data is available and what you can plan to accommodate.  Remember, just because it is in the standard does not mean you need that piece of data.

Once you have reviewed the standards, you need to get everyone involved: business users, a data mapper, a database administrator, trading partners and anyone else who might have a vested interest.  It might surprise you as to what data they will actually need and utilize.  Whether the data is used in the data warehouse or for reports it is important to identify your business needs.  Also, try to plan for future business requirements.  Just because you don’t use that piece of data right now doesn’t mean you might not need it as standards evolve.  You can start with a “wish list” and pare it down from there.  Keep in mind that just because you want to receive a particular piece of data, your translation software may not currently be set up to capture, your trading partner may not be able to accommodate, or your clearinghouse may not have that set up in their maps.  We all would like to have everything, but it is not always practical.

If you are converting to a new standard this is the chance to change things.  Just because it has always been done that way is no reason to continue – that may not be the best practice.  This gives you a chance to make things better and perhaps correct things that were not working right before.  If you are initiating a new transaction set, this is the perfect opportunity to grab the data you need and get everything set up right the first time.  This is where it is important to get the users involved.  As the person doing the research you may not think a piece of data is important, but to them it may be very necessary.

When you have identified all your data needs you are ready to move on to the next step – mapping the fields in the standards to your database.  We will talk about that in our next blog.

Have you initiated EDI? What data issues did you face? How did you overcome them?

Protecting Patient Data in an Interconnected Healthcare System

I will respect the privacy of my patients, for their problems are not disclosed to me that the world may know.  (Hippocratic Oath)

I recently read an article titled, “Protect Patient Data from an Inside Job” by Phil Neray of Health Management Technology, which stated, as many news organizations have, that in 2010 healthcare organizations were a  top target of data breaches.  All totaled, 214 healthcare organizations were breached in 2010 with a total of 6.3 million patients impacted by those security breaches. 

Open to the public 24/7, and being the keeper of the most private of all data, healthcare organizations are unlike any other in terms of security challenges.  No one questions the importance of privacy in the practice of medicine.  A doctor cannot expect a patient to openly disclose private information if that patient fears that they may be harmed by that disclosure.  Any information withheld out of fear can have a dramatic impact on the care received.

The Importance of Shared Data in Healthcare

Of course, by its very nature, providing the highest level of care requires sharing confidential information with colleagues.  You know the story if you have ever been a patient.  You may enter the healthcare system through the emergency room, go to the laboratory for testing, then off to radiology for an X-ray.  You then meet with a doctor and get a diagnosis.  The doctor then provides treatment where you may be sent to the operating room for surgery and then released to a rehabilitative services center or referred to your primary care physician for post treatment.   This data can be provided by electronic submission  to support research that can create innovations to further the quality of care.   The medical profession consists of multiple silos of specialized functions necessary to treat you as a patient.  Each department has its own procedures, specialized record keeping, best practices and scheduling. Improving patient care, and providing more efficient care, is the impetus behind the movement towards electronic health records (EHR) and Health Information Exchange (HIE) in the first place. EHR and HIE systems make it possible to rapidly transmit this data to make optimal care in the digital age a reality.   

Protecting Patients in the Modern Age

The issue is that since HIE systems essentially centralize data into data warehouse structures, fending off data breaches can become an even larger issue in the future.  As such, it is important that we effectively balance the importance of sharing patient information with the seemingly opposite, but vitally important, concept of keeping patient data private.   In his article, Neray recommends that the healthcare industry use the financial services industry, that dealt with data security issues under Sarbanes-Oxley and have been enjoying a decline in data breaches, as a model.  Data breaches have declined in the financial sector because financial companies have moved beyond perimeter security and no longer use a firewall as a standalone solution.  A frank discussion with any security administrator in financial services, I’ve enjoyed a few, will inform you that security breaches are most often an inside job.  These companies are actively monitoring sensitive information stored in databases.  Events are created to alert a security team about every small detail in order to prevent unauthorized access by prying eyes both inside and outside of the organization. 

I think that financial services does provide healthcare with a good model to follow.  However, it is important that healthcare organizations take control of data security issues now to prevent further reluctance of EHR and HIE technologies by a worried public.  In the end, both enhanced means for transmitting data, and better security of that data, are both necessary ingredients to enhanced healthcare.

Is Tokenization the solution for Protected Healthcare Information (PHI)?

One of my favorite things about the yearly HIMSS conference are the discussions that occur around new ways the healthcare technology community is dealing with the issues that arise as a result of increased innovation.  With medical identity theft looming, issues of the transmission of personal healthcare information over the Internet or the desire to share detailed medical records between medical institutions – a health information exchange, the time has come to find a solution besides encryption which simply may not be enough.  The credit card industry has addressed the issue of protecting credit card and e-commerce transactions with a process called tokenization.  Tokenization technology can, in theory, be used with sensitive data of all kinds including bank transactions, criminal records, vehicle driver information, loan applications, stock trading, voter registration, and, most importantly, medical records.

Tokenization is the process of replacing sensitive data with unique identification symbols that retain all the essential information without compromising its security. Tokenization has become popular as a means of bolstering the security of credit card and e-commerce transactions while minimizing the cost and complexity of compliance with industry standards and government regulations. With increasing regulation of protected healthcare information, tokenization is the right technology to address the transfer of sensitive information over public or private networks. 

In a credit card transaction, a token typically contains only the last four digits of the card number. The rest of the token consists of alphanumeric characters that represent miscellaneous cardholder information and data specific to the transaction underway. When an authorization request is made to verify the legitimacy of the transaction, the actual card number is used only in the initial request. The token is returned to the requester instead of the card number along with approval or rejection of the transaction. The token is stored in the point-of-sale (POS) system but the credit-card number is not.

Tokenization makes it more challenging for hackers to gain access to cardholder data, as compared with older systems in which credit card numbers were stored in databases and exchanged as visible text over networks. Tokenization improves on encryption technology by keeping sensitive information out of the data stream. With the proliferation of identity theft and the consequent increased risk of ruinous civil and criminal proceedings, many corporations are turning to tokenization to minimize exposure and cost while maximizing their own security and that of their customers. Healthcare needs to adopt the same technology for protected healthcare information (PHI).

Protected health information (PHI), under the US Health Insurance Portability and Accountability Act (HIPAA), is any information about health status, provision of health care, or payment for health care that can be linked to a specific individual. This is law can be interpreted rather broadly and includes any part of a patient’s medical record or payment history. Protected health information includes the following list of 18 identifiers must be treated with special care according to HIPAA:

  1. Names
  2. Addresses smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes
  3. Dates (other than year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older
  4. Phone numbers
  5. Fax numbers
  6. Electronic mail addresses
  7. Social Security numbers
  8. Medical record numbers
  9. Health plan beneficiary numbers
  10. Account numbers
  11. Certificate/license numbers
  12. Vehicle identifiers and serial numbers, including license plate numbers;
  13. Device identifiers and serial numbers;
  14. Web Uniform Resource Locators (URLs)
  15. Internet Protocol (IP) address numbers
  16. Biometric identifiers, including finger, retinal and voice prints
  17. Full face photographic images and any comparable images
  18. Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by the investigator to code the data)

The big question is how to implement the tokenization of protected healthcare information? The short answer is make it a “service” in a service-oriented architecture that talks to a tokenization server (redundant, of course). The tokenization server would contain the 18 or more key protected items and their corresponding tokens.  The service would retrieve the protected information temporarily for healthcare applications and updates, but would prevent local storage of the information to maintain control.  This tokenization process would be implemented in conjunction with an Enterprise Master Patient Index (EMPI) system for a healthcare organization.  The centralized server for protected health information would allow stronger security controls within an organization as well.

An implementation of tokenization will be a step-by-step process for a large healthcare organization and it will need to become seamless to key applications delivering patient information within security guidelines.  Some of the key steps to implementation will include:

  • Data discovery – creating an inventory to discover all of the places where protected healthcare information currently exists
  • Legacy data conversion – an examination of the databases, data warehouses and side systems in use throughout the organization
  • Token development and format – creating tokens in a way that fits easily into existing systems and doesn’t create confusion for other identifying numbers
  • Business rules modifications – modifying existing healthcare or medical records application software to use the tokenization service versus storing the patient information locally.

Will there be challenges from implementing tokenization?  Most certainly, however the risks and the potential for costs associated with the loss of regulated data can be exponential.  Let’s take a lesson from the credit card industry and address this critical issue before it becomes a legislated issue.

If you would like to discuss this tokenization idea or other healthcare-related topics, please stop by Perficient’s booth (#3681) at HIMSS on Monday, February 21, 2011 from 1:30 p.m. to 3:00 p.m. or Tuesday, February 22, 2011 from  2:00 – 5:00 p.m.  See you there!