Several years ago, we embarked on a journey that no other health IT company had taken to date: we participated in a study that dramatically shifted the e-prescribing landscape by adding controlled substances as a capability. I am happy to share that the Agency for Healthcare Research and Quality (AHRQ) released a video about the three-year project.

I’ve talked about our work to bring e-prescribing of controlled substances to market and the current state of the industry in previous blog posts and videos, but I wanted to get into some of the details that surrounded our AHRQ-funded study in Berkshire County, Massachusetts in this post.

Study Background

The DEA issued its Interim Final Rule on electronic prescribing of controlled substances in 2010. Several years before the ruling, we laid the groundwork for electronic prescribing of controlled substances in Berkshire County through an AHRQ-funded study. I had met Donald Burt, MD, a physician at Berkshire Health Systems (BHS), who highlighted some of his grievances with the inability to send controlled substance electronically, which included:

  • Using two systems for prescribing was nonsensical and resulted in disrupted workflow
  • Not only were handwritten prescriptions time consuming, they also put him and other physicians at risk for tampering and diversion
  • Berkshire County had a huge prescription drug abuse problem, exacerbated by an inability to track medications sent. In fact, BHS was funding its own program to monitor all controlled prescriptions

His grievances were not uncommon for physicians then, and today.

The project started to come together when I got Grant Carrow PhD on board. I approached Dr. Carrow, who became the Principal Investigator, to participate in the study because I was impressed with his understanding of the issue as well as his academic background.

At the time of the study, Dr. Carrow was also Director of the Drug Control Program for the Massachusetts Department of Public Health (MDPH). When Dr. Carrow and MDPH agreed to get involved, they put together a high-quality, academically complete project. Dr. Carrow was also instrumental in bringing both BHS and Brandeis University into the study. I am thankful to Dr. Carrow, as his work helped us get AHRQ funding. Other partners included pharmacies, the DEA (who provided a waiver), AHRQ, and Emdeon, the e-prescribing network that transmitted prescriptions between DrFirst and the pharmacies.

Spearheading Industry Transformation

Some people might want to know why we chose Berkshire County to do a pilot study. What better place to do a study on e-prescribing controlled substances than somewhere with a prescription drug abuse problem? Since DrFirst was already communicating with the DEA about possible solutions to e-prescribing of controlled substances, I received the green light from the DrFirst executive team. I then began gathering a team to participate in the study. You can learn more about the project by watching the AHRQ’s video:

 VIDEO: AHRQ Highlights Pioneer Electronic Prescribing of Controlled Substances Study

I hope you enjoy the video, and please feel free to share your thoughts in the comments section.

Where We Stand: E-prescribing of Controlled Substances Today

We’ve come a long way, but we’re still not at 100% of providers sending, and pharmacies accepting, controlled substances. So, where do we stand now?

  • Over 40% of pharmacies nationwide accept controlled substance e-prescriptions
  • 49 U.S. states have now legalized controlled substance e-prescribing
  • New York’s I-STOP deadline March 27, 2015; The law mandates controlled substance e-prescribing

For more information on controlled substances e-prescribing read our The Evolving Landscape for Electronic Prescribing of Controlled Substances white paper.

The AHRQ’s video reminds me, at a time when controlled substance e-prescribing is gaining momentum, of the real transformation we spearheaded and continue to foster.

About Peter Kaufman:

Schooled at MIT, Dr. Kaufman nurtured a strong interest in medical informatics while a Bowman Gray School of Medicine faculty member. After entering private practice he founded PiNK software in 1996 to produce EMR software, later becoming DrFirst’s chief medical officer upon its founding. He lectures nationally on various healthcare IT topics, and as a board certified gastroenterologist, he continues a limited clinical practice. Dr. Kaufman is a member of the Health IT Standards Committee, Privacy and Security Workgroup for ONC (Office of the National Coordinator for Healthcare Information Technology). Representing the American Gastroenterology Association’s (AGA), Dr. Kaufman is a delegate to the AMA and was the co-chair of the Physicians Electronic Health Record Consortium (PEHRC). He has participated on workgroups at CCHIT (stand-alone e-prescribing), HIMSS (e-prescribing), and NCPDP (e-prescribing).

Find all posts by Peter Kaufman | Visit Website

Add a comment

Recently, a colleague and I were talking about how times have changed. My colleague is a physician, recently retired from private practice, though he continues to see patients part time in a teaching environment. He is a key individual who has been and continues to be instrumental in the development of several healthcare IT standards nationwide, and a number of key processes within DrFirst. As usual, our discussions provided me with a valuable insight. “I remember a time, not that long ago,” he told me, “when the only identity proof required by a provider could be found on a wall. My medical school diplomas and post graduate board certifications hung on my office wall for many years, and it was one of the first things patients noticed on their first visit. It was the only identity they cared about, or needed — for at least the average person.” Unfortunately, in today’s complex and interconnected healthcare environment, such a straightforward and seemingly pristine approach is obviously insufficient. Providers must prove their identity and supply credentials outside of their person to person interactions with patients and peers, and often to computer systems, large organizations and professional licensing bodies that require more rigorous and repeatable identity proofing and credentialing processes.

As I have discussed in prior blog posts, the establishment of identity is not a straightforward process. The strength of the assertion about who someone really is and how we connect that assertion to a mechanism or “credential” by which that person may access information, can be fraught with both complexity and mundane redundancy. The process used to establish the identity, irrefutably and irrevocably attach it to a trusted attribute or credential for proof, and then test that credential reliably and without disruption. Once completed, all combine to define the usefulness and “strength” of the identity. When, as an industry, we began to utilize electronic medical records systems, we also created a correspondingly electronic need to restrict and control the means of access to, and security, and distribution of, private medical information, a.k.a. “Protected Health Information” or PHI as defined in the Federal HIPAA Privacy rule over 10 years ago.

This might have been made easier if there was such a thing as a central system in use by all providers. However, such a daydream is long behind us. Despite congressional reluctance to authorize a national patient identifier, we have seen a bit of progress with the establishment of a “National Provider Identifier.” This at least offers a workable though not perfect substitute for the much misused and abused DEA number, originally and exclusively intended to manage the prescription of Controlled Substances. However as an industry, we have spent the better part of the past 30 years envisioning new, improved and ever expanding computer systems and software applications to digitize and manage patients’ medical records. The goal is to more efficiently deal with the explosion of healthcare specialties and services dealing with an increasingly mobile population. Nevertheless, in the current environment, a practicing hospitalist or a physician on multiple clinical staffs may be forced to utilize as many as five or six separate, individual, and mutually exclusive computer systems, each of which independently sets and maintains identity controls and processes for on boarding, including periodic re-assessment. This creates a very heavy burden on everyone involved: the IT department, organizational management, and of course the provider.

What is an identity exchange?

In order to remove the burdens caused by the level of redundancy in on boarding across health care IT systems, we need to separate and consider distinct the three basic components of access: identity, credential, authority. In previous blog posts, I have introduced this requirement as a central component to solving this vexing problem. This blog post will examine the first of those components necessary to establish a secure, reusable, inexpensive framework from which we can begin to repair the current situation.

An identity exchange is a service that creates reusable assertions that might be called upon to identify an individual reliably and inexpensively. Unlike other existing exchange models in practice today, an identity exchange is a set of services, offered under a Trust Mark, that only establishes an identity using one or more knowledge based authentication (KBA) methods or using other established forms of identity proofing. An identity exchange is not meant to provide system access or to evaluate credentials. Its use culminates in reusable assertions that are marked according to their method, level of assurance, origin, provenance, and date of establishment. Subsequently, the assertion itself is bound to some reusable attribute that may be either chosen by the individual or signed by a third party, but is nonetheless unique and durable. It is vital that the resulting identity is thoroughly defined and documented according to accepted guidelines and that it be re-testable, according to a predefined schedule, to assure that it hasn’t changed after it was created.

Most importantly, though, an identity exchange serves one major purpose: to prevent the need to reestablish identity each time a person establishes contact with a new application or system, often characterized as “the relying party.” Since the management of a person’s identity is kept separate from the management of the credentials and the use of those credentials to gain access to particular system assets, it can be considered durable. The identity is not subject to change as access rules or authority change over time. A person’s identity remains intact regardless of how that identity is treated or considered over time. For example, if you are the person known as “Dr. John Public,” and have proven this fact to some level of assurance — within some trust framework’s definition, this fact may be held within the repository of an identity exchange. Doing so will enable applications to leverage this fact repeatedly, rather than cause you to reproduce it on demand each time it is needed.

Now, if the “Exchange” allows you to associate this identity (and the fact it was rigorously proven) with an attribute of your choosing, we can establish a straightforward “index” or “seed” to your identity. The exchange must also protect this index against duplication or use by anyone else. Once claimed by a user, it is irrevocably theirs. For purposes of discussion, let’s call that index attribute “unique name” and for this example, let’s say you set your unique name to “Tiger1234January.” Effectively, that unique name value would be associated with your identity and called upon in order to recall the circumstances under which that identity was proven and the date that that identity might expire. Applications wishing to start a process with the identity exchange would pass the “Tiger1234January” value to the exchange as a means to identify who they were attempting to validate. This is not a proxy for username, as it is the credential, not the unique name that effectively completes this validation. Knowing the value would only start the process, not define a key. If it alone were shared or compromised, there would be no loss of system integrity.

The identity exchange does not grant you access to an application, nor does it validate a credential in order to prove that the entity requesting access is in fact the person who has been given authority to do so. This is where many people get confused. An identity exchange is meant to play a very singular role, and requires that the application performs access management, and that the credential is separately validated through a distinct and different function apart from the identity exchange or the application itself. All three functions must be working together to grant access.

So you may be wondering why I feel it is so important.

Consider that “Identity” gives meaning to access granted by an application. It would be little use to an application administrator if it were impossible for him to associate a human with the authority he is enabling. By giving Dr. John Public access to key information, the application administrator is cognitively associating the person he knows as Dr. John Public with whatever credential he thinks identifies John. However, he is not the only one doing so. The application administrator’s use of an identity exchange releases him and others like him from the responsibility to determine who John actually is, and to make certain that John is not impersonated. It’s also very important to remember that the application or relying party can require its own proprietary policy that must be satisfied by the Identity Exchange steps prior to granting access rights. Consequently, these assertions can be made more formally, rigorously, and with greater levels of assurance, since they will be done only once. This strengthens the security of all systems.

Furthermore, once the relying party’s policy requirements are satisfied, its applications no longer have the need to associate human beings with access controls; they no longer have to store information that can be co-opted in the process of compromising those controls. Remembering that identity, access, and credentials will now be three separately managed processes, there will no longer be a single target for any nefarious individual wishing to fraudulently gain access.

This sets the stage for the emerging standards related to a general need to strengthen identity and credential management in healthcare. Recently, discussions at the IDESG, NSTIC, ONC, and related subcommittees have considered the need to begin a mandate that all healthcare related systems adhere to NIST LOA 3 standards at a minimum. This would effectively mark the end of usernames and passwords for healthcare system access, and will rely instead on more sophisticated credentials and processes to establish identity and associate it with an appropriate credential for each user. While this might be some time coming, it is most certainly more imminent with each breach we hear in the news, and for every person’s privacy that gets compromised either through carelessness or some fraudulent act.

Regardless of this movement, it may be inevitable that providers and their staff be issued multiple credentials for the foreseeable future. However, if we are to establish the level of security necessary to safeguard our information assets in healthcare, and if we are called upon to raise the implementation to one with more rigorous identity controls, an identity exchange will be vital and indispensable to making the entire process tenable for IT, administrative organization, and the providers themselves. Reducing redundancy and identity definition is a crucial step to the acceptance of more rigorously defined identities for providers and their staff.

How would it work?

In short, the identity exchange would amalgamate multiple identity sources, some of which may be emergent at the moment. That is, the traditional identity proofing resources (credit bureaus, information databanks, government entities, etc.) will continue to play a role. However, new resources may also play a role, and include other technologies, possibly even low tech or no tech approaches. It is possible that a combination of social media, and referred identity (the fact that if a large number of already trusted people can agree collaboratively that “Dr. John Public” is who he purports to be) can also be used in the identity proofing process. Another possibility is emerging that a “low trust” identity that has been used hundreds of times over a very long period may build itself into a more reliable “self-asserted” identity.

It is almost certain that some common identifier such as the “unique name” discussed above will be necessary in order to interact with the identity exchange. An application would provide this attribute in order to check the status of an identity that had been previously asserted, or to ask that credentials associated with that identity be verified. Furthermore, this “unique name” would be used within each application in order for access controls to be set. Rather than associate those controls with username as they do now, applications would associate authority and roles with the “unique name” instead.

When asked to authenticate a user, the identity exchange will interact with a credential exchange whose sole responsibility is to validate one or more credentials, such as a two factor authentication device, biometric, or other multifactor mechanism. The credential exchange is signaled using an identifier unique to the identity exchange, such as an internally generated globally unique identifier (GUID), or some other unintelligible value generated by the identity exchange programming.

In this way, the identity exchange will be blinded to the actions of both the application and the credential exchanges to which it connects. In other words, the identity exchange has no way to associate a person with the authority that has been granted to that person by any of the applications that person is using. Similarly, the identity exchange has no way to connect a particular credential to one of those individuals whose identity it manages. Future blog posts will detail the actions of the credential exchange and the application.

What value would it provide?

As I mentioned at the outset, in order to assert more rigorous controls on application access and identity management, we need a mechanism to simplify the process of establishing and maintaining reusable identities. These reusable identities can then be described as “interoperable.” The fact that they will be reusable is a key function, because we wish to reduce the number of redundant identity sources, practices, and general inconvenience facing providers today. Reusable, interoperable identities are vital, and at the center of the principles established by IDESG. The promotion of reusable identities is the first step on the road to establishing more secure and reliable controls, and reducing the costs normally associated with strong credential processes. In the end, we will establish an increase in the de facto security and privacy controls that will likely be required in the coming years, while reducing the vulnerability of all applications universally.

I strongly believe that the time has come to create such an exchange. There is much more to be said about this, and many challenges to face. Healthcare application vendors tend to hold tightly to established means of credentialing, and the concept of the identity exchange will certainly threaten those models. However, just as providers have had to become accustomed to a plethora of new digital systems as well as challenges to their provenance by intervening payers, the systems that serve them must quickly catch up and look beyond the diploma that once was their only identification. If patients can learn to access 21st century information, looking past that sheepskin, so should all healthcare applications.

About Eric Rosenfeld:

Eric Rosenfeld is the Chief Information Officer, having broad responsibility for all Information Technology at DrFirst, including software product development, computer operations, Quality Assurance, and Project Management. Mr. Rosenfeld possesses over 25 years of business and IT experience in companies throughout the health care industry. In March, 2010, he came to DrFirst from BlueCross BlueShield of Tennessee, where he was the Senior Vice President of Information Technology for BCBST’s wellness division. Mr Rosenfeld is an expert in the process of application design and development, project management, and process control.

Find all posts by Eric Rosenfeld | Visit Website

Add a comment

In this next installment of my blog series on increasing quality in the e-prescribing marketplace I want to focus on the question of provider behavior. As I mentioned in my introduction to this series, there is a tendency to place nearly all of the blame for e-prescribing quality issues squarely on the shoulders of providers, which I believe is largely counterproductive. At the same time, input errors from staff or providers are the primary cause for the overwhelming majority of quality issues in e-prescribing.

Put simply, physicians who are overwhelmed by heavy workloads and the incredible burden may fail to be precise and meticulous in writing prescriptions. One of the things I want to highlight in this series is that there are a number of ways in which the healthcare IT and e-prescribing industry can adjust e-prescribing software and in order to alter outcomes in e-prescribing and improve overall quality in the market place. In this blog, I want to tackle the “elephant in the room” by suggesting a series of strategies aimed at altering provider behavior.

First, however, I do want to call attention to a few things which providers need to do for themselves. The most transcendent of all of these changes needs to be a renewed focus on “self-policing.” Providers must slow down and pay increased attention to their work in e-prescribing if we are going to cut down on the number of needless errors. I understand that patient volumes are already large and are only growing larger as the population ages. In addition, more patients and more prescriptions mean that pharmacists are handling larger volumes of prescriptions. As such, there will be an increased risk of pharmacists not catching errors, leading to adverse reactions and an overall decrease in the quality of care provided by our healthcare system administers. There is no other way to see this picture.

In addition to paying more attention to the scripts that they are writing, it is also important for providers to avoid skipping important workflows in the interest of saving time. Prescriptions should not be renewed without first checking a patient’s current medication history. Alerts to medication reactions and patient allergies should not be quickly passed over by harried providers with a severe case of alert fatigue. The primary impetus for the development of HIT and its widespread standardization across the industry is the development of Clinical Decision Support (CDS), but when providers do not take the time to make adequate use of the features which vendors have built into their systems, CDS is not only ineffective, it is non-existent. To further support CDS, it would be helpful if vendors were more judicious in the number of alerts as a means of cutting down on alert fatigue, but providers also need to pay adequate attention to what could be highly impactful clinical information. There must be responsibility and accountability on both sides.

Finally, providers need to begin adapting to the new methods of script writing which e-prescribing requires. The old days of simply writing whatever one wants down on paper and letting the pharmacist ‘figure it out’ have long passed. Providers need to adapt in the interest of moving the healthcare industry forward. Having worked in the healthcare field for several decades, I am well aware that ‘adapt’ is not a word which providers typically look upon with enthusiasm. Like many professionals, physicians and other providers find process they like, which they then become accustomed to over the course of many years, and are therefore loath to change. But healthcare is going through a massive high-tech revolution, and change is inevitable. Failure to adapt to these changes will only make the healthcare industry lurch forward haphazardly, and providers are the most essential gear in the industry’s broader machine.

Having called attention to the changes which providers absolutely need to make in the way they approach e-prescribing, I now want to address what vendors can do to help support providers in improving e-prescribing quality. To me, these fall into two broad categories: training and feedback.

There is a very real need for more comprehensive training as part of the sale of healthcare IT products. Vendors need to focus on adapting their training programs in order to ensure that providers are being spoken to in “their” language, and that the reasoning for specific workflows is fully explained to the people who will be using them. As an adjunct instructor at two schools of pharmacy, and having attended many healthcare vendor training sessions, I would like to recommend that training sessions be broken down into comprehensible chunks. There is only so much information that the human mind can successfully absorb in one sitting, and most vendors try to get through training as quickly as possible. Making these simple changes will translate into improved product understanding and adoption on the part of providers.

Finally, I believe that vendors need to solicit the input and feedback from providers as they design their products. For a long time, the healthcare IT industry has been guilty of designing and developing products with very little provider input, and then passing these products on to their clients without ever having considered how the products will work within a real healthcare setting. Computer programmers and developers, for all of their wonderful talents, are not doctors—they don’t think like doctors, and they cannot be responsible for fitting products into a clinical setting that is dynamic, fast paced, and difficult. This is one area where I am particularly proud of DrFirst, because as a company we truly strive to put doctors first and foremost in the design of our products.

At essence, providers must be more attentive during the prescription writing process, and comply with workflow best practices. Healthcare IT companies need to consider the provider’s prescribing environment and process when developing products, and then deliver training that speaks to the providers’ needs. I truly believe that if we as an industry can accomplish these things, we will see a dramatic improvement in e-prescription quality.

About Michelle Soble-Lernor:

Michelle Soble-Lernor is DrFirst’s Principle Pharmacist, and works in our Clinical Quality Office. Michelle plays a leading role in ensuring the security, quality, and precision of DrFirst’s interactions with key stakeholders. She earned her BA in Pharmacy and her Master’s in Toxicology at the University of Arizona prior to receiving her MBA in Healthcare Management at Western International University. In addition to her duties at DrFirst, Ms. Soble-Lernor is also an active and influential voice within her pharmacy community, serving as a Clinical Instructor of Pharmacy Practice and Services for the University of Arizona’s pharmacy school, as well as an Adjunct Assistant Professor of Pharmacy Practice at Midwestern University Glendale’s pharmacy school. Ms. Soble-Lernor also continues to work as a retail pharmacist on a limited basis in order to stay abreast of new industry trends and dynamics.

Find all posts by Michelle Soble-Lernor | Visit Website

Add a comment

Health literacy, defined as the “the degree to which individuals have the capacity to obtain, process, and understand basic health information and services needed to make appropriate health decisions”,* is a growing concern within the U.S. as more Americans are diagnosed with multiple chronic diseases…chronic diseases that often require complicated self-care. When you factor in socioeconomic, language and familial concerns, you have a recipe for a rising segment of the population who are willing but unable to comprehend the information given to them by their healthcare providers.

The American Medication Association Foundation sponsored a National Assessment on Adult Literacy (NAAL) that reported only 12% of American adults demonstrated proficient health literacy and over one-third of Americans have difficulty following directions on a prescription drug label or childhood immunization schedules.** The consequence of miscommunications, on behalf of the provider or patient, can result in medical errors, reduced health outcomes and increased healthcare disparities.

To overcome these challenges try implementing the “ASK” sandwich.

Ask the Patient Questions
Many of us were told “when in doubt ask” or “no question is a stupid question.”  Draw information from your patient and help them understand that you can only support them to the point that they provide you insights into their experience.

Identify Health Risks & Conditions
Describe the healthcare challenges that require management and explain the consequence of inaction, such as risk factors for more serious chronic disease. Make the connection between the actions they can take and how their actions can protect them from more severe consequences that impact their quality of life. It’s important for patients to establish positive anchors that motivate them to achieve their personal health goals.

Ask Additional Questions to Understand the Behavioral & Socioeconomic Factors Contributing to their Health Status
Better understanding the patient’s ability to manage his or her care between office visits can be used to help tailor a self-care action plan. Here are a few common issues to consider reviewing with patients:

  • Financial Limitations – Ask the care team to locate prescription coupons or co-pay savings cards to limit the patient’s out of pocket expenses
  • Parental/Childcare Challenges – Offer virtual follow-up visits and consultation via phone or email. With emerging technologies, virtual meeting solutions may prove helpful to support real-time, bidirectional communication between office visits
  • Low Literacy – Refer patients to personal health records that visualize and help explain common elements of disease management plans. At minimum, these tools can help to encourage a more in depth dialogue and shed light into how much the patient understands about their health

One of the greatest assets you can deliver to your patients is empathy. Create a shame-free practice environment so that your patients understand on a deep level that nothing is too simple or embarrassing to share with you and your care team.

This blog is the first of a three-part blog series titled: “Empowered – Rethinking the Point of Encounter”

*  Lynn Nielsen-Bohlman (2004), Health Literacy: A Prescription to End Confusion, Washington DC: The National Academies Press
** Sheida White (2008), Assessing the Nation’s Health Literacy: Key Concepts and Findings of the National Assessment of Adult Literacy, Chicago: American Medical Association Foundation

About Maria Barhams:

Ms. Barhams joined DrFirst in 2014 as the director of population health after beginning her career at the National Institutes of Health (NIH) as a fellow in 2007. In her public service capacity, she leveraged her background in biology and public health/health services administration in various analyst, administrative, intramural, and extramural functions across the NIH. Most notably, Ms. Barhams supported the revision of clinical guidelines and risk stratification of a rare disease affecting patients with compromised immune systems. These guidelines were later adopted and published by the American Academy of Neurology. Ms. Barhams is passionate about public health and the rapid diffusion of evidence from research into real-world clinical settings to improve patient outcomes and reduce disparities. In her capacity at DrFirst, she supports the realization of this vision via DrFirst's technology solution, Patient Advisor.

Find all posts by Maria Barhams | Visit Website

Add a comment

In my last blog, I discussed the nature of identity and the reasons why identity management and the establishment of trust are very difficult and complex issues in healthcare and other industries. Identity is only half the problem. The other half, and unfortunately the one to which many incomplete solutions have been posed, is the establishment of digital credentials that tie to a person’s online identity. It seems that everyone has a solution to the improvement of digital credentials. Long ago, username and password combinations (e.g., the simplified “identity” surrogate) were the only mechanisms by which access might be granted to programs or data. Today, we appear to be beset with a wide and growing variety of credential types, including two – factor authentication, biometrics, out-of-band, and a number of creative mobile-based systems. While many of these are vast improvements over the traditional username and password combination, none of them alone will do the magic trick of securing an application at the level of assurance usually required or desired in healthcare. The real key to security in healthcare lies deeper, in the way applications work (regardless of the credential they use) and in the inherent frailty that comes when an application takes on the daunting identity/credential challenges alongside its own application logic.

Let’s start by examining what’s wrong with traditional credentials in the first place. Much has been written about this topic, especially lately, so I’ll cover it briefly:

  • Usernames and passwords are generally vulnerable, largely because they have to be memorable. Making anything memorable generally simplifies it, and the simpler a credential is the easier it is to impersonate it.
  • Even complex password schemes, like those that enforce a password consisting of uppercase and lowercase letters mixed with numerals and even special characters, are not really safe. Criminals seeking access will very rarely attempt to manually guess passwords. For over 20 years, password-cracking schemes and sophisticated software have been used to penetrate vulnerable accounts. Since many passwords are short enough to be memorable, this software makes quick work of the additional combinations afforded by adding 30-odd characters to the set used for the password. Speaking mathematically, a password that is eight characters long, using 62 possible characters in each position yields 628 or about 218 trillion combinations. This sounds like a lot, but in reality, systems trying several hundred thousand combinations per second can accomplish this task in a reasonable amount of time. Longer passwords would certainly make this task much harder, but many people resist password lengths in excess of eight characters despite the dramatic mathematical effect it would have on deliberate cracking schemes. In comparison, a 32 character password would be nearly impenetrable given current processor speeds, as it would yield 6232 or 2.2 * 1057 combinations, an improvement of nearly five orders of magnitude.
  • Despite password complexity, usernames and passwords are still vulnerable because they depend on human intervention, and may be learned or stolen by any number of means. Social exploits, phony websites, workplace espionage, key-loggers, virus and malware, and many other forms utilize this frailty to exploit human trust and behavior in order to gain access to systems and data.
  • Perhaps the biggest issue with traditional credentials, and in fact with credentials in general, is that each application establishes them individually and independently. Consequently, each provider, whether in a hospital setting or in a private practice, usually possesses many credentials simultaneously – one for each application they access. Hospitals tend to simplify this somewhat using single sign-on technology, but providers who access systems outside the hospital still have other credentials to use and remember. The more credentials a provider has, the more likely it is that the provider will reuse password values across systems or, worse yet, keep a written log of passwords so that he can keep them all straight. Finally, in the real world, whether logins and passwords are simple or complex, they are frequently shared voluntarily and inappropriately by end users who feel they have neither the time nor inclination to access secure data needed to accomplish specific tasks.

Recently, as a reaction to these vulnerabilities and shortcomings, hospitals have been discussing the need to demand higher levels of compliance among their peers and associates. Laboratories, imaging centers, physicians and their staff, ambulatory care and chronic care centers are being asked to tighten control as endpoints in the hospital ecosystem. Even insurance companies, exchanges, and health information service providers have considered tightening control by enforcing new and more stringent operational controls, technical software requirements, networking constraints, and workflow–impinging rules in order to stem the vulnerability created by reliance on traditional access controls. It’s a curious turn of events. Especially now that doctors and administrators alike utilize their own private, mobile technology at work, it seems futile to attempt a top-down, dictatorial strategy to change behavior. Furthermore, in a world already complicated by government regulation, additionally intrusive or expensive controls just seem like the wrong idea.

I do not mean to imply that stringent network, BYOD, and other related policies are in any way ineffective. They are necessary, and at the heart of any great solution. However the real problem runs much deeper and the healthcare industry needs a more innovative solution. Determined fraudsters and thieves will find holes in any strategy, but generally move around those that demand compliance with the greatest ease. Budgetary, resource, and expertise lapses often creates holes and opportunities for nefarious advantage.

The outlines of a plan

In order to be effective, I believe the healthcare IT industry must reevaluate its love affair with application-specific solutions and look to form a more impenetrable and distributed scheme that is at once simplifying, inexpensive, and easy to adopt. This is not a new dream, but rather one that has been in the works and imminent for some time. This vision has been promoted by several federal government agencies and institutes, particularly the National Institute of Standards and Technology (NIST) and its IDESG (The identity Ecosystem Group), along many of the proponents and related committees that have been involved and invested for over three years. It is in the spirit pioneered in those committees that I offer the outlines of a simple plan to overcome the vulnerabilities of both identity and credential management.

In short, I believe our plan should include the following:

  • A complete separation of identity management, credential management, and access control, management (also known as role-based authorities) into separate, independent system components. In other words, applications should no longer manage their own identities, bind them to exclusive credentials, and also define the authority or capabilities of a user. Doing so creates vulnerabilities and redundancies that must be avoided.
  • Each of these components must be blind to the actions of the others. There can be no functional or technical interdependence between these facets of the ecosystem. Any fraudster can gain no advantage unless all three aspects of the ecosystem are simultaneously compromised, which would be very unlikely. The only exception to this concept of “three-way blindness” would be through a stipulated legal process.
  • The use of username and password-based credentials should be curtailed or ended as soon as possible. In their place, multifactor, biometric and other credentials should be used. These tend to require far less memorization and repetitive action on the part of the user and are consequently more immune to theft or compromise.
  • The ecosystem must itself be extensible. Additional credential types, providers and operating parameters must be enabled as required by application logic. Identity sources, methods and levels must also be extensible.
  • A single, comprehensive Trust-mark standard must be envisioned, applied and enforced across all elements of the ecosystem. If the Trust-mark originates from a well-known and independently audited entity, or one with the authority to enforce it legally, it will become a compelling aspect of adoption for applications that might otherwise be slow or reluctant to comply.
  • The ecosystem must rely on well-documented standards for technical content, so that adoption is simple, well-defined and nonproprietary.

Each of these items is probably worthy of its own blog post. There are many potential obstacles, including the status quo, that stand between us and this goal. However, the effect such an ecosystem will have on the state of healthcare will be monumental; providers will no longer be troubled to own multiple credentials, applications will no longer continuously reinvent credentialing/identity proofing and access management, and the future of privacy and information security in healthcare applications will be finally assured.

Eric Rosenfeld’s Series on Identity Security in Healthcare:

1. Who is your physician and how do you know? Solving questions of identity in healthcare
2. The real key to security in healthcare in an online world

About Eric Rosenfeld:

Eric Rosenfeld is the Chief Information Officer, having broad responsibility for all Information Technology at DrFirst, including software product development, computer operations, Quality Assurance, and Project Management. Mr. Rosenfeld possesses over 25 years of business and IT experience in companies throughout the health care industry. In March, 2010, he came to DrFirst from BlueCross BlueShield of Tennessee, where he was the Senior Vice President of Information Technology for BCBST’s wellness division. Mr Rosenfeld is an expert in the process of application design and development, project management, and process control.

Find all posts by Eric Rosenfeld | Visit Website

Add a comment

Most of us take the concept of “identity” for granted. We know and recognize ourselves, our co-workers, family and friends and do not usually give a second thought to this phenomenon in our daily lives. We base these assumptions of identity on our memory and day-to-day interactions. More importantly, we trust these identities implicitly and act upon them automatically nearly every minute of our waking lives. Think about this — if everyone in your life was somehow magically removed from the Earth and replaced with an identical, look-alike copy, how would you be able to tell? You might be able to pick up on the change by asking questions or noticing a lack of knowledge of prior events, but some of the lesser players in your world might escape attention. Could you discern if the clerk at the local grocery was no longer the person you (fleetingly) knew, but rather someone else, posing as them? While it might be the basis for a science fiction story, the absurd nature of this example is actually close to the truth of the identity issue facing the healthcare industry today.

Within the healthcare industry, identity authentication poses perplexing issues for those engaged in creating transparency and interoperability for all parties in the healthcare ecosystem. Of course, the computer systems and databases used by physicians lack human empathy or insight. For them, identity is proven when a user presents some credential that gains them access to information. Hence, all access attempts to a system that use the same credential are indistinguishable from other attempts, despite who or what is behind them and whether they are presenting the credential honestly or with authorization. For example, how can we prove that a healthcare provider is who they purport to be? Who should prove that fact? How often should this proof be renewed?

The issue of identity becomes more complex as the number of credentials afforded a provider increases. In the past, providers have had one or two primary medical information systems with which they interact, usually located at their practice or place of work (hospital). Since the advent of Meaningful Use Stage 2, the rise of Health Insurance Exchanges (HIE) and Health Information Service (HIS) providers, the number of credentials a provider requires is rapidly rising. Despite recent pilot progress sponsored by the Identity Ecosystem Steering Group (IDESG) and the National Institute of Standards and Technology (NIST), we are still working to develop standards related to proving identity, and credentials that could be used to evidence that identity proof.

Proving identity is not easy, since it requires a number of cooperative steps and the willingness of a provider to answer questions or present existing identity proof that has already been established by a trusted source. In many cases, government issued photo identification may be used by a party to identify a physician. This is common practice in hiring, for example, and used in various other circumstances both within and outside of healthcare. Unfortunately, this level of proof has already been superseded by more rigorous processes, such as those required to enable a provider to electronically prescribe controlled substances (EPCS). Under controlled substance e-prescribing, a provider must be verified by a third party (not someone they work with or even the vendor offering e-prescribing). It must be based on financial data and verifiable with trusted sources.

As you can tell, trust is a central theme of the entire process. The essence of this trust is an acknowledgment of the certification given an organization and its processes to create a consistent and truthful result. The system or organization granting the provider access to a restricted process (as in controlled substance e-prescribing) or data (as would an HIE) must trust the entity doing the identity proofing of that provider. They must also trust the method by which that identity was proven. In turn, the identity provider must trust the answers to whatever criteria is placed before the healthcare provider (the subject). Usually, this process starts with a piece of private information supplied by the subject, such as an account number. Indeed, the subject must also trust that the identity provider is using information they are supplying only for purposes that the subject intends. Once the identity is proven, it is used by applications wishing to offer exclusive access to the subject/healthcare provider. Those applications must trust that the identity provider did their job effectively and indisputably. If any single link in this trust chain is broken, the entire chain fails and the subject’s identity is not conclusively proven.

Providing everything goes well, the fact that the identity has been proven is “bound” to a credential; a means to gain access to a system. We use the term “bound” to mean that the credential is assigned irrevocably to the identity of the person using it, the same person whose identity has just been proven.

Usernames and passwords have historically been popular credentials, but are now increasingly coming under fire due to their fragility and relatively insecure nature. Other credentials have emerged as more secure and less vulnerable, including two factor authentication devices (Public key infrastructure [PKI], one-time password, etc.) and multifactor devices that creatively use smart phones and other technology to avoid the use of passwords altogether. Regardless of the type of credential and its strength, it is the systemic equivalent of the identity it represents. That is, for purposes of system access, we assume that once the bound credential is validated, the intended provider is authenticated and allowed to enter that system. The credential and the identity are interchangeable, for purposes of access control.

In today’s healthcare environment, identity is ordinarily defined with a particular purpose in mind. That is, it’s defined separately by each application wishing to establish an identity control. This is unfortunate, because forming this identity and the trust that surrounds it is often time-consuming, expensive, and distracting to healthcare providers who must be intimately involved in the process. Consequently, providers often find themselves repeating the identity proofing process for each application that needs this level of assurance. Additionally, they are left with multiple credentials, one per application. This is quickly becoming untenable for several reasons:

  • the process is expensive, and these costs are very often shifted to the provider or the hospital
  • having multiple credentials that essentially prove the same fact can lead to inconsistencies as well as redundancies, since each application, identity proofer, and credential is separately managed and possibly vulnerable in different ways
  • the provider must remember which credential is to be used with each application, since most credentials are not transferable
  • there is no way to identify a fraudulent use of a credential across applications, since there is no gold standard for either identity or credential interoperability

The process of proving an identity and the trusting the provider, identity proofer and application is complex. The existing solutions in the marketplace do not meet a single standard, nor has such a standard been adequately articulated, at least not yet. There are many current workgroups addressing this deficiency, and all of them are reaching for the same brass ring: to create an interoperable, inexpensive, reusable identity standard that can be shared between applications without any degradation of trust; and, to identify an inexpensive solution to the federation of credentials, allowing them to be interchangeable with uniformly trustable results.

In the future, it should be unnecessary to create application access controls, security controls, and so on, for each application individually. Providers should not be forced to repeatedly prove their identity, nor wrestle with a host of application credential controls. The credentials that remain should include only those whose technology surpasses any password control, including biometric, multifactor, and similar approaches.

In future blog posts, I will expand on this theme and discuss the work at DrFirst and other leading firms that are addressing this issue. Together, we are forming answers to these difficult problems. Our success will signal the beginning of a new era in healthcare systems management.

About Eric Rosenfeld:

Eric Rosenfeld is the Chief Information Officer, having broad responsibility for all Information Technology at DrFirst, including software product development, computer operations, Quality Assurance, and Project Management. Mr. Rosenfeld possesses over 25 years of business and IT experience in companies throughout the health care industry. In March, 2010, he came to DrFirst from BlueCross BlueShield of Tennessee, where he was the Senior Vice President of Information Technology for BCBST’s wellness division. Mr Rosenfeld is an expert in the process of application design and development, project management, and process control.

Find all posts by Eric Rosenfeld | Visit Website

Add a comment


Whether you're looking for the latest news in healthcare technology, best practices for clinical and patient care, or to stay up to date on the latest federal and state healthcare legislation, you’ve come to the right place. The DrFirst blog is your source of insight, analysis and helpful content, to help you and your patients succeed in the ever-changing healthcare industry.