A peeve: The auto-logoff in Health IT

John Halamka wrote a blog post today that addressed some issues of the negativity that are affecting health IT. I wish I could be as positive as Dr. Halamka. Unfortunately, I am just not wired that way. My world view tends to be that of a critic. In this post I will take up a long-held pet peeve concerning an element of technical security used to protect HIT.

Last week John Moehrke wrote a blog about privacy and security in Meaningful Use Stages 1 and 2. His third point concerned inactivity timeouts or auto-logoffs. This seems like a good idea at first glance but inexpert implementation can cause a real barrier for users of HIT. I will provide two examples from my immediate experience. The hospital where I work has what would be classified as a HIMSS Stage 2 or Stage 3 EHR. There is a physician portal that encompasses a number of applications. Separate time outs are built into the portal and some of the applications and they do not communicate with each other. Today, I was reviewing the past medical treatments for a complex patient in ChartMaxx. I was right in the middle of scrolling through one of the medical documents for this patient when a time out window popped up (no prior warning was given). I was required to log into the application again with my username and password. This took me completely out of the patient's chart and the document I was reading even though I was in the act of reading the document and actively scrolling. I had to reenter the patient's medical record number, locate the instance of treatment I was reviewing and then reopen the document. In my opinion this is not efficient care. I know it is a waste of my time. Someone did not consider clinician workflow when the auto-logoff was designed. But that is not the only example of problems I run into frequently with HIT applications at my hospital.


In the hospital, radiographs are electronically accessed via a PACS system. The PACS requires separate credentials (username and password) to access the system from those either to use a computer workstation or the physician portal. PACS also has its own auto-logoff utility. It is set to time out after a few minutes of inactivity. This might be fine for a clinical area where the screens are close to area of high patient and visitor and patient traffic but it can create a lot of problems when surgeons use images in a long operating room case in which they need to review x-ray images. I like to log on to the system, access my patient's images that I will use in surgery and put them up on the screen so that I can refer to them while the OR team runs a patient safety checklist before the start of surgery to help in the process that confirms that we are operating at the correct site. Perhaps you can imagine my consternation when 15 minutes later, I have washed my hands, placed the surgical drapes and am about to start surgery when the program has timed out and all the carefully selected images are gone, and now I am scrubbed. Having a few minute auto-logoff for the OR, probably the most controlled environment in the hospital, does not make sense.


There are some solutions. 1) All users should be trained and re-trained about the importance of logging out when they are no longer using a computer that provides access to protected health information. If compliance were 100 percent then auto logoff would not be necessary. 2) The auto logoff could be designed so that this feature could be configured by users (not administrators of the IT system) to allow adjustment based on clinical requirements and an assessment of the risk of data breach at the workstation's physical location. 3) There are proximity controls based on infrared sensors or smartcard technology that can be used to control or limit access to user terminals.


There is not a perfect solution for every situation. Some approaches certainly are more user-friendly. Blanket application of a single time-out or auto-logoff policy is guaranteed to frustrate clinical users. A flexible approach, based on a risk assessment strategy, makes the most sense to me.

Recommendations for HIMSS 12: my favorite activities

Attendees to HIMSS 12 in Las Vegas, NV in February should do some advanced planning in order to garner the most benefit from the conference. A good place to start is the dynamic HIMSS 12 brochure. For comprehensive information refer to the conference website. This post will cover my personal favorites based on attending the last few national meetings.



This year HIMSS takes place from Monday, February 20 through Friday, February 24. Monday is devoted to preconference Workshops and Symposia (Nursing Informatics Symposium is on Sunday afternoon.) I have found it very worthwhile to attend one of these sessions. Subject areas cover a wide field in health IT so everyone should be able to find one that is apropos. My difficulty has always been narrowing the choices. For example, this year I would love to attend: Physician's IT Symposium, HIE Symposium, Privacy and Security Workshop and Secondary Use of Data Symposium. I wish HIMSS would record (video and audio) these sessions and make them available for a reasonable charge after the conference. The full meeting gets underway on Tuesday.


Each day's activities kickoff with Keynote speakers taking the floor in the largest meeting room. HIMSS often makes a big production of these early morning sessions. Consider bringing earplugs or some cotton to preserve your hearing. This year's speakers will include innovators, government officials (the National Coordinator for Health IT, Dr. Mostashari), and other talented individuals. I think it's worth braving the crowds to attend these informative and entertaining sessions. Following this I usually head for one of the many educational sessions that run throughout the mornings and afternoons. I look for sessions with acclaimed experts in a field. This is a good chance to match a face with one of the names you have seen in print or heard on a webinar. Continuing education credits are available for most professionals and CPHIMS participants. You can claim your credits and print certificates at one of the computer kiosks spread around the convention corridors. Another way to build up CE credits is to stop off and listen to a few of the eSessions. The presentations are often less than 30 minutes. I take advantage of these vignettes to multitask- learn something new while resting my feet after standing and walking a bit too much. Of course, no convention would be complete without a visit to the trade show.


You can spend hours walking the floors of the exhibit floor, learning about the latest and greatest vendor offerings for health IT. You will have to be efficient because the exhibit floor will only be open for two and a half days this year. One area I never miss is the Interoperability Showcase. Each year it gets bigger and better. This is the place to see the potential of HIT actually working in real life use case demos. Most of us just imagine the possibilities. If you are interested in health information exchange, interoperability, privacy and security, IT enabled patient care devices, or the various federal health initiatives, plan to spend at least an hour here. The Interoperability Showcase is usually located somewhat off the beaten path at one extreme end of the exhibit hall but is absolutely worth the time and effort it takes to visit.


Not all activities are carefully organized. I like to spend some time in the HIMSS Bookstore, looking through indices and scanning chapters before I decide to buy a publication. The Bookstore is easy to find as it is always located in a high traffic area. If you are looking for a job or considering career advancement in health IT then visit HIMSS JobMine, University Row, and the Career Services Center for information, contacts, and ideas. Topic-focused knowledge centers are new this year. These should be worthwhile checking out. I am especially interested in dropping in on the Mobile Health knowledge center. I am predicting that this will be one of the busier sites at HIMSS 12. We don't seem to be able to get enough of mHealth at this point.


Last but not least, there are networking and socializing opportunities. I look forward to the Physician Community breakfast and Arizona HIMSS Chapter reception. If you register for HIMSS 12 you can go to the opening reception. This is a great way to launch your week at the convention and meet some new friends. So, make you plans now, leave some flex time for extemporaneous activities, and see you in Las Vegas.

HIT Outlook for 2012: A crystal ball.

Now that we are in the last month of 2011 it is time to look forward to 2012. Here are my choices for what I think will be the hot topics in health information technology for the coming year.


1. Meaningful Use Stage 2 NPRM. I know it seems like Stage 1 started just yesterday but the plans for new requirements in Stage 2 are quite mature. The Federal Advisory committees have made their recommendations to the Secretary of Health and Human Services and the NPRM should be published in the first half of 2012. Mostly this should be a modulation of Stage 1 requirements with some items shifting from menu to core and the performance percentages ratcheting upwards toward 100 percent. There will be some new electronic quality measures to report. The good news for everyone is that implementation of Stage 2 has been delayed from 2013 to 2014. Watch for the number of hospitals and eligible providers qualifying Meaningful Use Stage 1 incentives to increase. In my opinion, the number of those who have met all the requirements of Stage 1 to date is disappointing. There have been 8,001 eligible providers and 302 eligible hospitals that have passed the gauntlet successfully through the end of Sept. 2011. Judge the level of participation for yourself. There will be more reports available on best practices and lessons learned to help those aiming to qualify for Stage 1 in 2012. I think the challenge is greatest for smaller practices and organizations that lack the IT resources to achieve meaningful use.


2. Preparation for ICD 10. Preparations for ICD 10 should ramp up significantly in 2012. Those who wait until later will be way behind the curve and could face drastic financial consequences. The costs and work needed to implement ICD 10 by the health care system in the US are astronomical but cannot be avoided. Many providers will need to significantly modify how they document clinical care if their coding (and by association, their income) is to be accurate. Coders will need to train on what amounts to a totally new code structure. The need for coders to learn and understand additional medical and procedural terminology cannot be minimized. Multiple IT systems will have to be upgraded to accommodate the new codes. Finally, cooperation between all elements of the health care community will need to be expedited in order to pull off the monumental changes that are required.


3. Health Information Exchange Initiatives. The vision of improved health care for the US through HIT cannot be realized without robust health information exchange. Stage 1 Meaningful Use requirements primarily were for tests of HIE capabilities. I expect Stage 2 requirements to be more demanding. Efforts to achieve broader adoption of health information exchange have been hindered by a number of factors including: lack of sufficient HIE infrastructure, reluctance of providers to share information, low adoption rates for EHRs, complex governance issues, and a paucity of models that demonstrate financial sustainability independent of government grants. Earlier this year, I expected that there would be an explosion in the use of the Direct Project specifications. This apparently has not occurred. I think that HIE will make significant progress in 2012 as the State HIE projects move from the drawing board to actual implementations. Developments in provider directories, digital certificate management, consumer consent assurance, workflow optimization, and EHR capability toward interoperable exchange of clinical summary documents through CDA should all be watched because these capabilities will speed HIE adoption. Also, watch for progress on the query health initiative. I think there are a lot of challenges for this project, not the least of which are yet to be developed specifications, lack of infrastructure for large scale HIE, and patient identity management issues, especially given the lack of national unique patient identifiers. On the horizon are mobile computing apps that may circumvent issues related to interoperability, lack of HIE infrastructure, and disparate silos of clinical information through use of cloud computing that can transform relatively unwieldy data to easy to manage webpage applications.


4. Mobile computing. It's not too late to jump on the mobile computing bandwagon but the front of the train representing mobile applications has already left the station. There has been an explosion in the use of mobile devices and applications by clinicians and patients alike. The actual potential of the technology has yet to be imagined. I think mobile apps and cloud computing will revolutionize how we collect and use data in the health care field. The FDA is hovering near the forefront to apply some braking action through its regulatory powers and represents a risk that developers must take into consideration. Security and privacy requirements are especially important but already many solutions are available through proper use of technology, policy, and thorough user training and monitoring.


5. The Learning Health Care System. I thought this was a bit of a silly term when I first heard of it. After all, how can a system learn? It is really people who learn. But this is part of the Federal Health IT Strategic Plan 2011-2015 so I think I'll adopt it. As professionals in the health care field, each of us should commit to and invest in life-long learning. We should benefit from a growing volume of information in 2012 as reports are returned from the projects developed under federal grant programs such as the Beacon Community, State Level HIE grants, SHARP grants, and HIT workforce development efforts. Look for useful feedback drawn from the experiences of the Regional Extension Centers. And this just scratches the surface of information sources. Try to attend one of the meetings of national organizations such as HIMSS, AHIMA, AMDIS, and others this coming year.

Dr. Bob's HIT thoughts-Looking forward to 2012

I have not posted anything new over the last three months. There are several reasons. First, my clinical activities as an orthopedic surgeon have taken more of my time and energy. Also, I have not been involved in HIT projects recently so there has been less motivation to write. I taught a master's level class, taking up a number of case studies in HIT, in September so I dedicated August to preparation and September to teaching.


I am looking forward to the new year. The IHE North American Connectathon is being held in Chicago in mid-January again this year. I will reprise my role as a voluntary monitor, testing the interoperability of IHE profiles adopted by numerous vendors. This will be my fourth year consecutive year volunteering. Each year I have come away wondering why implementation of these profiles has not been more rapid in vendor systems and user sites. I have usually been involved in testing the various Patient Care Coordination profiles that utilize a variety of CDA templates. I tested a new profile last year-RFD- request form for data capture. This is a well-thought out and versatile method to manage forms and pre-populate fields on forms to diminish the data entry demands on clinicians. There are many use cases including patient safety reporting, research, and public health. Although the weather in Chicago in January can be dicey, the Connectathon is always a good way to start off the year.
Just a month later, HIMSS 2012 will kick-off in Las Vegas. It will be nice to have the conference in the west for a change. There is still a long drive by personal vehicle from Yuma involved but I will gladly forego the challenges of travel via the commercial carriers. I did not have the same conundrum choosing a pre-conference educational offering as I did last year (see planning for HIMSS 11.) That is not to say that there aren't quite a number of tempting alternatives. If I had a twin, one of us would go to "HIE: The year of implementation, collaboration, and beyond." I think for most of us the "and beyond" will be the operant situation. Then again, for me, the Secondary use of Data Symposium, and the Privacy and Security Workshops are intriguing. Message to HIMSS-here is a way to make some dough and serve the community-professionally record and capture video of these sessions and offer them for sale after the conference.

Now that I think about it, planning for HIMSS 2012 warrants its own post. I'll add it to the list of topics that I am thinking of writing about in the coming weeks. The impetus to write seems to be gaining strength. I still have a few thoughts so standby.

Where are the HIT experts?

I was listening in on the HIT Standards NwHIN Power Team call this week. At the end of each meeting there is time for public comment. It is rare that someone from the public calls in. This week someone did. The gist of the comment was that the caller was alarmed at the lack of subject matter expertise in the area the committee was addressing. Since the discussion was about real world implementations of NwHIN Exchange, Connect, and the Direct Project, the best expertise would come from vendor/developers and current implementers. Discussion centered on completion of a table referencing maturity of specifications and extent of industry adoption. The caller had actually taken part in the development of a number of the specifications being discussed and had real-world experience in the area of discussion. Committee members apparently made a number or misstatements or actual erroneous statements. The caller's reasonable recommendation was for the committee to solicit information from subject matter experts before they make their final recommendations next month to the HIT Standards Committee. It is funny but I had the same thoughts about obtaining more expert information myself while listening in on the call. No response was offered to the caller's recommendation. In the past, a number of the FACA work groups have convened panels of experts to provide testimony and recommendations and have incorporated this information into final recommendations.


Some of my concerns with the federal HIT efforts since the change of administrations are that the effort has become fragmented, there often is duplication of effort, more coordination and oversight is needed, and previous groups of expert volunteers with a broad spectrum of representation have been disbanded. New efforts have been started from scratch, overseen by contractors whose skills are more in the realm of project management than technological expertise. The S&I Framework is one example. I was frustrated when listening to some of the early meetings because many of the participants were unaware of previous HIT efforts and many of their understandings were mistaken. Perhaps I was part of the problem because my intolerance led me to pursue other activities. Lately, I have been glad to see that more real experts are joining the S&I Framework effort.

The Perfect Storm Barometer: Which type of precipitation carries the greatest risk for clinicians?

Pundits have been predicting the perfect storm for the last few years. This refers to the confluence of clinical and administrative practice impacts of the change from HIPAA X12 4010 to 5010, the CMS Meaningful Use incentive program, and the change from the diagnostic coding system ICD-9 to ICD-10 in the U.S. Other changes are also in the background such as electronic prescribing of controlled substances (DEA) and changes in the regulation of EHRs and medical devices (FDA.) These initiatives will impact all practices ranging from those in the largest integrated delivery networks to the solo provider. The greatest effect will be on small practices because they generally do not have an abundance of resources and highly trained experts needed to fulfill the new requirements. The migration, already underway, from small practices to much larger groups and employed positions is likely to become a stampede. Retirement will be a course some will choose that could worsen the physician shortage in the U.S. So if there are limited resources, how does one deploy available resources now?


The Arizona chapter of HIMSS, the Arizona chapter of AHIMA, the Arizona Regional Extension Center, and a number of other organizations sponsored an educational session about ICD-10 last Friday. We learned that the U.S. is the last major western country to make the switch. Asian countries including China, Korea, and Japan among others have already made the change. You might wonder why the change to ICD-10 is being brought up now if it isn't even scheduled to take effect until October 1, 2013. Aren't there more pressing items? For example, the hospital where I work published an information sheet this month about the ICD-10 transition. Information technology staff recommended a 3 to 6 month period for training. What their message failed to convey was the need for a substantial risk-based analysis of current state, planned changes, gap analysis, need to coordinate software and hardware updates in multiple systems, implementation testing, increased staffing needs and productivity loss across the spectrum of the organization.


Experience in Canada and Australia showed a 10-50 percent loss of productivity of clinicians and coders that lasted up to a year. In many cases, productivity never returned to the condition before the changeover. The reasons are that ICD-10 has much more specificity than ICD-9. There are also many more codes for both diagnoses and procedures. That means that coding staff are going to need to be much more knowledgeable in anatomy, physiology, and the differences between similar sounding surgical procedures. Clinicians are going to need to document their work much more thoroughly than most have been accustomed to doing in the past or risk denial of claims and/or reductions in payments. All of this will take everyone more time. It is a scary thought but clinicians should probably plan on a 25% reduction in practice income for 6 months to a year.


Useful risk mitigation strategies are: educate yourself about the coming changes-early and frequently, communicate with all your vendors and work collaboratively to install and test all systems involved in the changeover well ahead of Oct. 1, 2013, plan coding scenarios to test coder and clinician readiness, plan to accommodate the loss of productivity and income. Technical solutions such a computer assisted coding have promise but are not ready for routine widespread use. Having a certified EHR will make it easier to collect and code patient data needed for ICD-10 but many systems will need to be upgraded. Consider whether Meaningful Use or ICD-10 compliance is more important in deciding on how you deploy your limited resources. I know one consultant who thinks that ICD-10 should be the priority because it poses the greatest risk to the financial health of a medical practice.

Digital certificates: Uses in health information exchange- final in series

This post is the last I have currently planned on introducing the topic of the trust framework and digital certificates. The first post in this series addressed the concept of a trust framework. I discussed the role of certificate authorities in helping establish trust among information exchange partners. I provided links to sites that explain how certificate authorities perform identity proofing by following policies and procedures that help define various levels of trust. The second post explored the difference between electronic signatures and digital signatures. Certificates are used with the latter to enable cryptographic technologies that can be used to insure data integrity and non-repudiation. Now I want to discuss two other important uses for digital certificates-user authentication and data encryption.

Digital certificates are a hot topic of discussion in various arenas that are leading the way in health information technology. Both of the two FACA committees, the HIT Standards Committee and HIT Policy Committee, have sponsored meetings of work groups and the entire committee to delve into issues dealing with digital certificates. The use of digital certificates was a core element in the design of the Direct Project. Pilot projects of HwHIN Direct are all dealing with the management of digital certificates. Finally, the Standards and Interoperability Framework sponsored by ONC has several work groups working on digital certificate management and provider directories. The reason for all this overlapping work is that use of digital certificates is central to the user authentication process. Many of the health information exchange transactions are founded on the use two-way exchange of digital certificates (based on strong identity proofing policies and strategies) to assure end point identities. Directories are one way health information exchange users locate the digital certificates of their partners. NIST has prepared an excellent and well-illustrated publication that thoroughly explains the authentication process. It is not easy reading but explains all the concepts that are important for one to truly understand the authentication processes currently used in health information technology. Don't be confused by terminology. Digital certificate, token, and key can be used interchangeably.

The final use of digital certificates is to power the Public Key Infrastructure that is used to encrypt data. I recommend another NIST publication as a reference to help understand the uses of symmetric and asymmetric encryption. This Wikipedia page may also be helpful. We know that the federal rule on data breaches strongly encourages encryption technology. Also, data encryption was designed into the Direct Project specification. I cannot imagine anyone sending unencrypted protected health information over the public internet in this day and age. Furthermore, it is probably a good risk mitigation strategy to encrypt most protected health information, whether it is in transit or at rest on disk storage. The rash of successful network attacks in multiple information technology realms keeps HIT executives and security experts up at night.

HIMSS Virtual Conference 2011: Closing Keynote-an exceptional presentation

The HIMSS Virtual Conference ran last Wednesday and Thursday. Meaningful Use seemed to be the key topic of focus. The sessions that I had time to view were generally instructive and interesting. The closing keynote was altogether different though.


The content and visual impact of the keynote presented by Dan DeMaioNewton of Monster Worldwide were unique. I haven't seen such an impressive slide presentation since thirty years ago when dual slide projectors and screens were first used in a medical conference talk. You have to be "old" to remember that now primitive technology. Last Thursday graphics, color, and animation were integrated in a fashion that truly amplified what the speaker had to say. I realized that the bar for presentations had suddenly been raised. I anticipate that others will be spending a lot of time and money to exceed this new standard. The presentation would have been remarkable if only for its visual impact but it provided more.


One of the themes of discussion considered HIT hiring practices and prospects. The question was " what is more important to employers- a degree (formal education in the field) or experience?" Mr. DeMaioNewton stated categorically that a degree was a necessary prerequisite. During further discussion, he allowed that experience was also important. Then, only yesterday, I was reading a discussion string on LinkedIn by those seeking employment in HIT. Most of the posts seemed to indicate that employers usually asking for a minimum of three years of experience for the positions they were attempting to fill. Up front at least, employers are looking for experienced personnel. I think that there will be continuing demands for HIT staff and fewer qualified individuals to fill the positions. Eventually the demand for staff will dilute out strict employer requirements for both training and experience. For the present, employers are still in the driver's seat so recent grads are going to face an uphill battle to break into the ranks of HIT professionals. That has been my personal experience anyway.


Another topic provided advice that was instructive. What do you do when you have a supervisor or potential supervisor who knows less than you? This is a situation that may prevent one from landing or keeping a job. Often, the supervisor doesn't want anyone around that knows more than they. They build fiefdoms of power and drive away those with more skill. Surprisingly, corporate culture often supports and encourages this management style. Mr. DeMaioNewton made the point that there are well-run companies that seek and value excellent employees. Good workers owe it to themselves not to tolerate work environments that stymie their enthusiasm and creativity. They should look for organizations where their special skills are recognized and rewarded. Just yesterday I read of a company whose hiring practices were based on finding the best people possible and then finding a job for them to do. The trick is finding the enlightened organizations.

Introduction to electronic signatures and digital certificates

Below is a summary I prepared awhile back for an Arizona Health-e Connection committee of which I was a member. This provides an introduction to the concept of digital certificates, though at a very basic level. I visited several websites to obtain the information needed to prepare the summary. As a caveat, I am not a technical expert in this area so I cannot attest to complete accuracy.


Electronic Signature:
There may be some confusion concerning the difference between electronic signatures and digital signatures. The most significant difference is that electronic signatures do not require the use of digital certificates.

An electronic signature is comparable to a seal or an electronic version of signature stamp. It is any legally recognized electronic means that indicates that a person adopts the contents of an electronic message. When recognized under the law, electronic signatures have the same legal consequences as the more traditional forms of executing documents. The electronic signature shows that the user has applied that symbol to indicate intent to sign. It is important that the electronic symbol be related specifically to the party who is signing, that there is proof the symbol was applied with the intent to sign, that the data being signed can be proven to be the original data, and be such that all parties to a signature are allowed to have independent copies. An electronic signature actually displays an image of you handwriting signature or a visual mark within the document to illustrate your consent towards a document’s contents and uniquely identifies you as a signer. It is permanently attached to a document like a handwritten signature on paper. It does not work well for multiply signed documents because of validation check steps that detect any changes (including a new signature) to the document. Some of the laws that apply to electronic signatures include: The U.S. E-Signature Act of 2000, Uniform Electronic Transactions Act (UETA), and FDA 21 CFR part II.

Digital Signature:
An electronic signature may incorporate a digital signature if it uses cryptographic methods to assure both message integrity and authenticity (non-repudiation.) The message integrity mechanisms will readily detect any changes in a digitally signed document. All current cryptogenic digital signature schemes require that the recipient have a way to obtain the sender’s public key (digital certificate) with assurances (trust) that the public key and sender identity belong together. The message integrity measures must assure that neither the attestation nor the value of the public key can be surreptitiously changed.

Digital signatures are created by hashing data (a cryptographic process) to produce a large number that uniquely identifies the contents in such a manner that any change would no longer produce the same number. This is a counter-measure to Man in the Middle attacks. That number is then encrypted with a person’s encryption key to prove that it belongs to the same person associated with the key. Public Key Cryptography uses two encryption keys that are mathematically related to one another yet one key cannot be derived from an analysis of the other key. This is often called asymmetric encryption because the key used to encrypt (private key) is not the same key that is used to decrypt (public key.) The public key can safely be given to others so they can use that key to decrypt information encrypted with the associated private key. It is critical to keep private key private. This may require technical and/or physical privacy protections. Private keys are stored on disc, servers, or smart cards.
Certificates
In cryptography, a public key certificate is an electronic document that uses a digital signature to bind together a public key with an identity-includes information such as name, organization, address, etc. The certificate can be used to verify that a public key belongs to an individual. In a typical public key infrastructure (PKI) scheme, the signature will contain information about the certificate authority (CA) that issued the certificate. The most common use of certificates is for HTTPS-based web sites. A web site operator obtains a certificate by applying to a certificate provider (CA.) The certificate provider requests contact email address for the website from a public domain name registrar and checks that the published address and email address match. The CA is also known as a Trusted Third Party (TTP.) It is critical to note for health information exchange purposes that the level of trust is determined by the policies and procedures for identity proofing followed by the CA.

A future post will discuss use of digital certificates for health IT purposes in more detail. Having a grasp of this information is essential if one is to understand the current controversies and activity at the national level concerning health information exchange, the Nw-HIN, The Direct Project, and Providers Directories.



Sources:

http://www.wikipedia.com/
www.esignform.com/ElectronicSignatures.jsp
www.silanis.com/resource-center/articles/electronic-signatures-vs-digital-signatures.html

Trusted Identities

My last post discussed the trust framework many believe is a necessary prerequisite for protecting private information as health information exchange becomes more wide- spread. This post will take up the subject of trusted identities. Central to this discussion will be an understanding of digital certificates and how they are used. There is an ecosystem built around digital certificates that few clinicians understand. While I am not an expert in the privacy and security field, I have taken an interest in learning more about this topic so I can outline some of the basics. This information could not be timelier. On May 23rd during the meeting of the Privacy and Security Tiger Team of the Health Information Technology Policy Committee (see agenda and slides) a presentation on digital certificates was a major topic on the agenda. Yesterday, May 24th, there was an interesting exchange between two knowledgeable bloggers (Dr. John Halamka and John Moehrke) about certificate management and provider directories. And today the S&I Framework managed by ONC held its first work group meeting on digital certificates and directories. It was evident from the open discussion that there is a wide disparity of opinion about the course ahead.


One of the major prerequisites for electronic health information exchange is that the partners involved in the transfer of private patient information know and trust each other's identity. Most are familiar with the concept of trusted identities because of experience with online banking and e-commerce. There are any number of reasons why this is a challenge when health information exchange is considered. Often, the parties to information exchange do not know each other personally. Also, the most practical techniques utilize the public Internet infrastructure. We know that there are numerous sophisticated malicious and criminal users of the Internet ready to modify or steal information and health care providers have both moral and regulatory obligations to protect personal health information. The federal government has a significant stake in identity management. A very informative draft synopsis, National Strategy for Trusted Identities in Cyberspace was published last year and is a must read for those with interest in this area. If you read this document you will note frequent reference to the concept of a trust framework and ecosystem that was the subject of my last post. Now we will review how identity is currently established in cyberspace.


There are non-cryptogenic and cryptogenic methods to assert an identity. The former take advantage of one or more of the following: something we know, something we have (may use cryptogenic features), or something we are. The most familiar non-cryptogenic method is something we know- usernames, passwords, and answers to secret questions. What we are consist of biometrics- fingerprints, retinal patterns, and facial appearance, for example. Cryptogenic methods often utilize tokens-also known as keys or digital certificates. Digital certificates are associated with a number of electronic privacy and security functions everyone will recognize- they are used for electronic authentication processes, they are a required component of many encryption processes, and they are utilized when creating digital signatures.


A digital certificate is either software or hardware based. A good introduction to digital certificates is found here. The X.509 standard is a well-accepted and widely utilized standard. Digital certificates are issued by a Certificate Authority (CA). The certificate authorities perform identity proofing whereby they verify that their customers are who they say they are. The thoroughness of the identity proofing is determined by the policy and procedures established by each CA. This can range from something as simple as collecting/assigning username and password assertions to requiring in-person verification of identity documentation and additional information. The process for becoming a CA has few requirements. Acquiring the least trustworthy certificates involves creating the certificate code using the X.509 standard and then self-signing. Most CAs employ more robust identity proofing procedures. The important point is that different CAs engender different levels of trust. A good resource for an in-depth introduction to levels of trust is this NIST publication.

Special requirements concerning CAs that issue certificates in the health information exchange realm can be expected soon. The computer systems operated by agencies of the federal government already only accept certificates from officially vetted CAs. In order for EHRs to send information to CMS, ONC, or CDC, they will need to use digital certificates issued by federally approved CAs. This a key concern to implementations of the Direct Project. The federal advisory committees will continue to evaluate the relevant issues this summer so stand-by.


I still need to discuss how certificates are discovered by information exchange partners, exchanged, and used. But those are hot topics for future posts.

The Trust Framework in HIE

One of the major barriers to more rapid expansion of health information exchange has been concern about protection of patient privacy. Therefore it is critical for the health IT community to develop foundational policies and procedures to provide reasonable assurance that private information of patients will be protected. On the one hand, there is no lack of regulatory privacy protections currently. Consider the HIPAA privacy rule and Meaningful Use stage 1 requirements, for example. However, some question whether current policies and technologies are mature enough to adequately protect personal health information. The frequent media coverage of large and small data breaches, including those that are the responsibility of health care entities, does little to engender public confidence. So what efforts are currently underway?



There are numerous governmental, public, and private groups working on this challenge. The Office of the President produced a draft federal plan that addressed cyber security issues in 2006. More recently the Privacy and Security Tiger Team of the Health Information Technology Policy Committee (HITPC) and the Privacy and Security Standards Workgroup of the Health Information Technology Standards Committee (HITSC) have each been tackling various aspects of protecting information privacy. The archives of previous meetings available at the ONC website are a rich source of information concerning their work. A recurrent theme is the need for an underlying trust framework to enable wider adoption of electronic health information exchange, especially if transport will utilize the public Internet infrastructure. Let's learn more about the meaning of a trust framework.


There are numerous components to a trust framework. The purpose of the framework at its most basic level is to ensure that partners involved in health information exchange can trust each other. One of the first steps is developing the policies, governance, procedures, and technology needed to authenticate one party to the other in order to facilitate access control decisions. A good explanation of a trust framework is provided in a course produced last year by the National eHealth Collaborative. NHIN 104 explains how the federal government has chosen to develop a trust framework to support NHIN Exchange. This trust framework concept can be scaled to encompass general health information exchange across the US. The subject for my next post will be Trusted Identity.

Reasons Specialists should consider using Regional Extension Centers

Last week I attended the Western States Summit and Trade Show sponsored by Arizona Health-e Connection. I learned a lot about several of the Regional Extension Center programs in the western states. Many specialists have been excluded from early participation. Reasons are both regulatory and financial. I gained some insights that I want to share. I think there are good reasons for specialists to engage the services of their Regional Extension Center.


The Regional Extension Centers (RECs) that have begun providing services to targeted Priority Primary Care Practitioners (PPCPs.) These providers are offered free or deeply discounted services to help them to adopt and meaningfully use EHRs. Services that are provided vary from one center to another but usually include vendor selection assistance, practice readiness evaluation, process improvement, change management, software and hardware contracting, discounted purchase plans, general information technology technical support, consulting on health information exchanges, and helping practices meet the challenges of achieving Meaningful Use so they can qualify for the CMS or Medicaid incentive programs. RECs so far have primarily focused on signing-up the required quota of PPCPs. To many it appears that specialists have been left to fend for themselves.


RECs are constrained by limitations of an adequately trained health information technology workforce. The workforce training program under HITEC were designed to solve this problem but it remains to be seen whether graduates will have the skills that the RECs need. Although the federal government has provided over $500 million if funding for the RECs, the program funding is limited when one considers the number of potential customers in the US. Furthermore, the RECs are having difficulty developing a business model that will sustain them once the grant funds are exhausted. They have difficulty determining fees they will charge providers not defined by the priority definition. Finally, non-covered clinicians have been reluctant to pay for the services that the RECs can provide. There are some real benefits that may be worth the cost.


One of the most difficult tasks with respect to health IT for clinicians is selecting an EHR vendor. Most small practices do not have the resources to go through the process of preparing requests for proposal and then vetting responders. Most busy clinicians just do not have the time or expertise to do a good job. However, many of the RECs are helping select one or more vendors to recommend to their clinician community. Another costly and time-consuming task is software licensing and hardware acquisition. Usually vendors offer boilerplate contracts that are slanted towards their benefit. Clinicians owe it to themselves to strive for a more balanced agreement. RECs often have invested in the preparation of balanced contract models for use by their enrollees.


Another advantage RECs can offer is lower licensing and hardware costs because they have the clout of volume purchasing. Think mini-Walmarts. The individual clinician would never be able to negotiate from this position of strength. Once a system is purchased the work does not end. Eligible providers are trying to qualify for Meaningful Use incentive payments. The training goals for clinicians and vendors often diverge once the system is configured and installed. Many vendors do not offer the services needed to help clinicians achieve Meaningful Use. The job for clinicians goes way beyond simply purchasing a certified EHR. The EHR must be used in a fashion described by the regulations with compliance on core and menu measures as well as reporting a variety of quality measures. The assistance of RECs will prove pivotal for many trying to qualify for Meaningful Use.


Finally, don't forget that we still are waiting to learn what the requirements will be for Meaningful Use stages 2 and 3. Software, hardware, and workflows will need to be periodically updated. This will probably require clinicians to seek ongoing technical assistance. The proposed stage 2 regulation most likely will be published in late December 2011. EHR users should expect an escalating list of requirements. Hopefully, the RECs will develop a sustainability model so they can provide needed services into the future for both primary care clinicians and their specialist colleagues.

Quarterly Index Update 2011-1st Quarter Dr. Bob's HIT Thoughts

A Commercial Web-based HIE Offering from Verizon                                         July 20, 2010

Breach Notification-Part 1                                                                                Oct. 15, 2009

Breach Notification-Part 2                                                                                Oct. 26, 2009

Certification                                                                                                    July 29, 2009

Certification Follow-up                                                                                     Aug. 19, 2009

Clinical Decision Support Systems                                                                     Mar. 23, 2011

Clinician Workflow                                                                                          April 11, 2010

Consumer Preferences                                                                                     Nov. 2, 2009

Dr. Blumenthal--An Inspirational Keynote Address at HIMSS10                            Mar. 7, 2010

EHR's for Surgeons/specialists                                                                          Nov. 19, 2010

EHR Safety                                                                                                      Feb. 21, 2010

EMR Certification Revisited                                                                              Nov. 17, 2009

EMR Usability                                                                                                   Nov. 22, 2009

Future Role for HITSP?                                                                                      Dec. 2, 2009

Handheld Devices-the Mobile Clinician                                                               Jan. 9, 2010

Health Information Exchange                                                                             Aug. 18, 2009

Health IT Ontologies of the Future                                                                     Jan. 12, 2011

Health IT Workforce Training                                                                            Dec. 27, 2009

HIMSS 11 ARRA Usability Symposium                                                                 Mar. 2, 2011

HIT Workforce Training                                                                                    Dec. 14, 2009

Imaging and Meaningful Use Debate                                                                  Jan. 27, 2011

Information Exchange Patterns                                                                          May 28, 2010

IFR on Standards and NPRM on Meaningful Use                                                   Feb. 16, 2010

Introduction                                                                                                      July 17, 2009

It's all about workflow                                                                                       Mar. 31, 2010

Meaningful Use and Incentives to adopt HIT                                                       July 21, 2009

Messages vs. Documents                                                                                  June 16, 2010

More Thoughts on Documents                                                                           Sept. 6, 2010

My Favorite Day at HIMSS 11                                                                            Mar. 3, 2011

NA Connectathon 2011                                                                                    Jan. 22, 2011

Online Education                                                                                             Sept.10, 2009

Online Graduate Degrees-My Experience                                                            Nov. 18, 2009

Optionality and Interoperability in Health Care Software                                     Dec. 6, 2010

Outlook for New Workforce Trainees                                                                 July 25, 2010

Patient Portals                                                                                                  Mar. 30, 2011

PCAST Report Thoughts                                                                                    Feb. 11, 2011

Planning for HIMSS11                                                                                        Dec. 1, 2010

Provider Directories                                                                                          Mar. 31, 2011

Quality Reporting                                                                                              Sept. 30, 2009

Reconciliation-an unmet Challenge                                                                     Sept. 14, 2009

State Grants for Health Information Exchange                                                    June 18, 2010

Summary of the HIT Policy Committee Workgroup hearing                                 Mar. 15, 2010

on EHR Safety

The Direct Project Goes Live                                                                            Mar. 1, 2011

Thought on the NHIN                                                                                       Mar. 18, 2010

Provider Directories

Interest in provider directories has increased as efforts to promote health information exchange have spread across the country. Federal policy, through ARRA, has also provided a strong impetus. Directories offer access to the information users need to contact partners for the exchange of health information. The federal advisory committees, both the Health Information Technology Policy Committee (HITPC) and the Health Information Technology Standards Committee (HITSC), have established work groups to help develop policy and select standards that deal with directories. Two flavors of directories have been envisioned by these work groups. Entity Level Provider Directories (ELPDs) could be thought of as listing mostly large enterprises with more than one provider such as hospitals, group practices, payors, etc. The entity would be responsible for routing information and protecting privacy and security of information within its walls. On the other hand, Individual Level Provider Directories (ILPDs) would provide information about individual providers. What are the purposes of directories?



Directories function like electronic white/yellow pages. The information they contain might include basic demographics (names, addresses, phone numbers etc.), electronic addressing information (URLs) of the anticipated recipient, and digital certificates or links to certificates (certificates fulfill a number of very important privacy and security roles-they are used for authentication, digital signatures, and are the keys used to encrypt and decrypt protected health information), and information about types of information exchange applications supported. Some directories deliver the entire directory on user request. Others utilize a query function so that users can select filters to locate the specific information they are seeking. How are directories established?


There are a number of approaches being used to set up directories. First the sources of data must be identified. Software and hardware configurations must be determined. An entity must be selected that will take the responsibility of hosting the directory. Directory information must be maintained so that the information is accurate and up-to-date. Those with experience managing directories have found this to be a real challenge. The business model chosen for the directory should provide guidance for financing the establishment and on-going operating expenses. Directories are easier to manage when they serve a limited geographic or functional area. Nationwide information exchange would most likely depend on a federated model of interoperable directories. The actual architecture at this level can become complex. Some of the standards used in directories, such as Lightweight Directory Access Protocol (LDAP) are mature and well established. Others are still being developed and tested. Many of the currently functioning directories were home-grown and employ proprietary software. For more information concerning directories look at the first part of the meeting slide deck of the HITSC Privacy and Security WG meeting of March 24th.


A reasonable question is: why do we need directories at all? It is possible search for providers using the Internet or we can dial information on the telephone. Once we have a telephone number, then the other contact information may be just a call away. I think the answer is that directories can facilitate these manual processes and help make them more efficient. Of course, once contact information is located it can be stored on one's own system, much like we store contact information for email systems.


There are problems related to directories. They do not scale easily, as mentioned previously. Another problem is that many clinicians work at a number of institutions or provide care and use EHRs at multiple sites. Trying to determine which of all the possible contact addresses would be the correct one for the purpose intended will require an exercise in logic and some luck. Furthermore, having two different types of directories may create a level of complexity that may be difficult for all but the most tech savvy users to navigate. Directories may present more complexity than is necessary. For example, the contact information needed to use the Nw-HIN Direct specification requires just two pieces of information: a URL for the recipient and the associated digital certificate. These can be transferred using old-fashioned email.


The HITPC and HITSC will be completing their discussion on the two types of provider directories over the next few months. Then they will make recommendations to the Office of the National Coordinator for Meaningful Use stages 2 and 3. It will be an interesting process to keep an eye on.

Patient Portals

Patient Portals



A Federal priority for health information technology in the U.S. is patient engagement. The aim is to involve patients more directly in their medical care, especially for those with chronic diseases, to improve outcomes and reduce costs. One of the key principles is to provide information to patients in a more transparent, easy to use format so that information can be used for improved medical management and to support behavior modification when it is needed. Patient portals offer EHR owners a method to meet some of the Meaningful Use stage 1 requirements. Portals vary in functionality so one-size-fits-all certainly does not apply.


One of the primary functions of a patient portal is to provide access to a patient's medical record. This can open up the entire chart, certain predetermined sections, or a summary document such as a CCD or CCR. Options include the ability only to view data or the possibility of uploading information to a home device or personal health record. Some portals allow patients to make contributions to the record such as correction of errors, annotations and other patient-generated types of data. Other functions have also been enabled by some portal designers. Popular features include the ability of patients to request medication refills online, patient mediated appointment scheduling, and secure email interchange with a clinician or office staff. Other portals offer bill payment options, ways to complete medical history questionnaires, patient education materials, and even social media site links.


One idea is to give patients more control over their medical information. As many know, consent for release of information has been a challenging policy and technical barrier to more robust information exchange. There are those who think that the patient should be solely in control of information flow by uploading all their health information to a personal health record. Then the patient could decide to whom to release information, which information, for what purposes of use, and for how long. This clearly represents an optimistic view of the health care community's ability to engage patients. Experience to date with large patient portal implementations has shown that only a minority of patients make use portals. Consumer adoption of PHRs has likewise been disappointing.


The Direct Project specification, as it is rolled out and implemented by major EHR vendors, may be a game-changer for both use of portals and adoption of PHRs. Direct should make it easier to direct the push of information from EHRs to PHRs so that the workflow becomes more automated and "easy" to perform.


There have been some concerns about privacy issues. Patients accessing portals often are authenticated by a single factor through use of user names and passwords. This is a relatively weak method for user identification. Furthermore, EHR owners are concerned that use of patient portals could expose them to data breaches and malicious attacks. These issues will have to be addressed through policy and technology development as we move through the more advanced stages of Meaningful Use.

Clinical Decision Support Systems

Clinical Decision Support



Clinical decision support (CDS) is going to be an important element of Meaningful Use Stages 2 and 3. Decision support functions will go far beyond those of drug allergy alerts and drug interaction checking that are necessary in Stage 1. In this post I will discuss diagnostic CDS. Wikipedia has an excellent general introductory discussion of CDS. You might also want to check the links to Isabel and SimulConsult. These are two examples of diagnostic CDS systems that are already commercially available. The former uses subject matter experts to generate content and the latter utilizes a computational wiki.


There have been several times in my career where diagnostic CDS would have been helpful. First, one must understand how doctors establish diagnoses. Usually this is done via a series of heuristics, rules of thumb, that often work very efficiently for the diagnosis of common conditions. The problem with heuristics is that there are a number of biases that can lead one in the wrong direction and thus to the wrong diagnosis. If the diagnosis for a patient is not correct, then the treatment instituted is likely to be incorrect. Let me provide a few examples from my clinical experience.


Years ago, I evaluated a patient in the ortho clinic with wrist pain. His usual clinician was away so I was seeing the patient. He had been treated for several months with non-steroidal anti-inflammatories with minimal relief of symptoms. Overuse syndromes, minor sprains, and arthritis are common causes of joint pain so the working diagnosis was one of these. I reviewed his previous x-rays and was struck by the marked washing out of mineral (a finding known as osteopenia) from all the wrist bones. I recalled that among the possible etiologies of this x-ray finding is tuberculosis. It also turned out that the patient had a racial background that showed a susceptibility to tuberculosis infection. I performed a synovial biopsy of the wrist that came back positive for TB at 4 weeks. The treatment was changed from NSAIDs to triple anti-tuberculous antibiotic therapy. The initial treating physician thought the problem a common one. Here availability bias resulted in a diagnostic error. Now I would like to relate another example.


I was called to the operating room to see a patient with an infected foot. The treating surgeon was a very good orthopedists. He was taking a reasonable approach by treating the presumed infection/ulcer with surgery and antibiotics. The patient had what appeared to be a large ulcer with pus at his heel/instep area. Initially, there did not appear to be a good reason for this patient to have a spontaneous foot infection. As a consultant, I carefully reviewed the chart. Two data elements that initially were not given proper weight led me to the correct diagnosis. The patient had a history of inflammatory bowel disease. In fact, he had a small fistula from bowel to his anterior abdominal wall (this is characteristic of regional enteritis, one of the inflammatory bowel diseases.) Also, the very compulsive ward nurses took a photograph of the initial appearance of the foot. That photo showed a bullous lesion (a clear blister) rather than a pustule (abscess.) Only a few conditions cause bullae. Since I had an interest in dermatology as a medical student I knew where to look for the diagnostic label. Pyoderma gangranosum is a skin condition associated with inflammatory bowel disease that starts as a bullous lesion. The diagnosis is made by clinical history, appearance of the lesion, and microscopy of a biopsy of the lesion. The treatment, surprisingly, is high dose intravenous steroids, something we would never consider in the treatment of infections because steroids inhibit the body’s immune defenses. The healing process was slow once the treatment was changed but the patient did not require further surgery. The heuristic bias here was representativeness.


It is possible that both of these incorrect diagnoses could have been avoided if the treating physicians had had EHRs with diagnostic CDS running in the background. Then the diagnosis in the first case would have keyed on the differential of diffuse periarticular osteopenia- either the radiologist or the orthopedist would have needed to enter the proper term in the record. In the second case, an entry of a bullous skin lesion on the physical exam or a skin biopsy narrative would have been needed to feed the CDS system with the necessary data to help with the correct diagnosis. This emphasizes the point that use of CDS is not cookbook medicine. To have good CDS you have to have expert clinicians who can provide the terms from history, physical exam, laboratory and x-ray studies that when coded properly will allow the CDS system to do its job. Otherwise we have the problem of garbage-in, garbage-out. A recent post on John Moehrke's blog discusses some of the data gathering issues with CDS systems as well as some relevant privacy concerns.


One of the problem with heuristics is that the probabilities are not really what the clinician thinks. Bayes' theorem is a mathematical formula that addresses probability of diagnoses before and after tests. This is familiar to many who work in the CDS field but not often considered or used by others. Clinicians are generally not well trained in probability theory as it relates to diagnosis and interpretation of tests. Other important statistical terms that should be considered in clinical diagnosis are sensitivity, specificity, positive predictive value, negative predictive value, and the accuracy of given tests. One also needs to know which of these statistical measures regarding tests are most important to weigh when “ruling in” a condition or in “ruling out” a condition. This tragically hit too close to home recently when my brother-in-law died suddenly from a pulmonary embolism.


Early one week he had sudden onset of sharp right-sided chest/abdominal/flank pain. He was seen by a physician's assistant at an urgent care center. He was discharged with a recommendation to obtain an abdominal ultrasound on an elective basis. Several days later he got on an airplane and traveled from the west coast to the midwest. The evening of arrival he experienced severe right sided flank pain, shortness of breath, low grade fever, low blood oxygen content, and hemoptysis. The differential included pneumonia and pulmonary embolism. The history, physical, and lab tests should have led to the conclusion based on probabilities that pulmonary embolism was just as likely as pneumonia. When a CT angiogram of the chest did not show evidence of an embolism then the clinicians wrongly concluded that he had pneumonia. The bias here was anchoring. Treatment was with antibiotics and pulmonary support. Further studies should have been done that most likely would have revealed the correct diagnosis. Several days after discharge from the hospital and another cross-country airplane trip, my brother-in-law collapsed at home and was dead 2 hours later. Postmortem showed no signs of pneumonia but rather acute and subacute pulmonary embolism. This devastated my family. I cannot help but wonder if a good CDS system had been used that the clinicians would have been reminded to do the correct tests and then institute the correct treatment with anticoagulants (blood thinners) rather than antibiotics. This is exactly what diagnostic CDS is all about. It would have saved his life.