The Interim Final Rule on Standards

Yesterday at 4:15pm, HHS/ONC released the Interim Final Rule (IFR) - Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.

Pages 79-81 contain the content and vocabulary standards

Page 85 contains the privacy standards.

Let's examine the major recommendations.

The standards selected leverage the hard work done by HITSP, Consolidated Health Informatics, Federal Health Architecture, NCVHS, and government agency efforts . The IFR notes that unless marked with the following superscripts, all of the adopted standards are from the ONC process that took place prior to the enactment of the HITECH Act or are required by other HHS regulations.

A number sign “#” indicates that the HIT Standards Committee recommended this standard to the National Coordinator but it was not part of the prior ONC process.

An asterisk “*” indicates that the standard was neither recommended by the HIT Standards Committee nor part of the prior ONC process.

A plus sign “+” as mentioned above indicates a standard that is not a voluntary consensus standard.

The content and vocabulary standards selected includes Adopted Standard(s) to Support Meaningful Use Stage 1 (2011) and Candidate Standard(s) to Support Meaningful Use Stage 2 (2013).

1. Patient Summary Record

The adopted content standard is HL7 CDA R2 CCD Level 2 or ASTM CCR. The candidate content standard is the hope that this will be converged to a single standard based on HIT Standards Committee recommendations. As I said in my Genius of the AND blog, I truly believe that CCD and CCR is the most parsimonious set of content standards for the summary record in 2009. I'm hopeful that HL7 and ASTM will continue their work together, simplifying the XML of CCD so that CCD and CCR can converge into a single approach which makes implementation easier for all.

Of interest, page 66 of the IFR notes that CCR must be parsed by all EHRs even if CCD is used. Per the IFR - "A final example would be, if an eligible professional uses Certified EHR Technology that has implemented the continuity of care document (CCD) standard for the exchange of a patient summary record and receives a patient summary record formatted in the continuity of care record (CCR) standard, their Certified EHR Technology must be capable of interpreting the information within the CCR message and displaying it in human readable format. We do not expressly state how this should be accomplished or in what format human readable information should be displayed (e.g., information in a CCR message could be converted to a text file or PDF). We only require that Certified EHR Technology must be capable of performing this function. We believe this requirement is critical and have included it to allow flexibility in the marketplace during meaningful use Stage 1 and to prevent good faith efforts to exchange information from going to waste (i.e., information is exchanged, but is unreadable to both Certified EHR Technology (machine readable) and humans)."

The adopted vocabulary standards for problem lists are the applicable HIPAA code set required by law (i.e.,ICD-9-CM) or SNOMED CT. The candidate standards are the applicable HIPAA code set required by law (e.g.,ICD-10-CM) or SNOMED CT. My hope is that SNOMED CT adoption is accelerated and that ICD-10's role will be limited to a back office function. Widespread implementation of ICD-10 will be costly and brings little added value to clinicians, while SNOMED CT captures clinical observations very well, enabling decision support and better quality measurement.

The adopted vocabulary standards for medications are any code set from an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm+ (note the + indicating RxNorm is not a consensus standard from an SDO, it's a product of the National Library of Medicine). For a complete list of the allowable vocabularies, see the NLM list which includes:

GS - 10/01/2009 (Gold Standard Alchemy); MDDB - 10/07/2009 (Master Drug Data Base. Medi-Span, a division of Wolters Kluwer Health); MMSL - 10/01/2009 (Multum MediSource Lexicon); MMX - 09/28/2009 (Micromedex DRUGDEX); MSH - 08/17/2009 (Medical Subject Headings (MeSH)); MTHFDA - 8/28/2009 (FDA National Drug Code Directory); MTHSPL - 10/28/2009 (FDA Structured Product Labels); NDDF - 10/02/2009 (First DataBank NDDF Plus Source Vocabulary); SNOMED CT - 07/31/2009 (SNOMED Clinical Terms (drug information) SNOMED International); VANDF - 10/07/2009 (Veterans Health Administration National Drug File). Also, FDA Unique Ingredient Identifiers (UNII) are a component of RxNorm.

The candidate vocabulary standard is RxNorm. I believe that the EHRs will continue to use proprietary standards internally for many years to come, but will need to map to RxNorm for all data exchanged.

The adopted vocabulary standard for allergies is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary standard is the Unique Ingredient Identifier (UNII). This makes great sense, since it will take vendors and self built system operators several years to implement controlled allergy vocabularies throughout their products.

The adopted vocabulary standards for procedures are the applicable HIPAA code set required by law (i.e.,ICD-9-CM) or CPT-4. The candidate standards are the applicable HIPAA code set required by law (e.g.,ICD-10-CM) or CPT-4. Of all the vocabulary standards mentioned in the Interim Final Rule, only one, CPT-4, requires payment for its use. I hope that HHS licenses CPT-4 for general use just as it has licensed SNOMED-CT. This will significantly reduce the implementation burden.

The adopted vocabulary standard for Vital signs is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary is a CDA template. This makes sense. I'm a fan of CDA templates to make CDA easier to implement.

The adopted vocabulary standard for units of measure is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary is UCUM. This is a very reasonable approach, giving commercial and hospital labs the time they need to implement a controlled unit of measure vocabulary standard.

2. Drug Formulary Check

The adopted content standard for Drug Formulary Check is the Applicable Part D standard required by law (i.e., NCPDP Formulary & Benefits Standard 1.0). The candidate vocabulary standard will also be whatever is required by Part D. This standard is widely deployed and there are no credible alternatives.

3. e-Prescribing

The adopted content standard for e-Prescribing is NCPDP script 8.1 or NCPDP script 10.6. The candidate standard is NCPDP Script 10.6. We debated this at the HIT Standards Committee, hoping that NCPDP 10.6 could be accelerated, but it is a reasonable compromise to offer some transition time.

The adopted vocabulary standards are the same as for the Patient Summary Record above.

4. Administrative Transactions

The adopted and candidate standards for Administrative Transactions are those required by HIPAA i.e. 4010 now and 5010 in 2013. This is expected.

5. Quality Reporting

The adopted content standard for quality reporting is the CMS PQRI 2008 Registry XML Specification#,+ (note that this means it was suggested by the HIT Standards Committee and not by HITSP, it's not an SDO product but was produced by CMS). The candidate standards are those to be suggested by the HIT Standards Committee. We debated this at the HIT Standards Committee because QRDA is an emerging standard for quality reporting but not a widely implemented one. This glide path is reasonable, but does require implementers to change course - implementing PQRI XML now and possibly QRDA or other standards later. It will be interesting to follow the comments on this one - maybe PQRI and QRDA should be allowed now to prevent this rework.

6. Submission of Lab Results to Public Health Agencies

The adopted content standard for lab reporting is HL7 2.5.1. The candidate standards are potential newer versions to be recommended by the HIT Standards Committee such as CDA documents. This is very reasonable given that all lab transactions in the country currently use HL7 2.x approaches.

The adopted vocabulary standard is LOINC when LOINC codes have been received from a laboratory. The candidate vocabulary standards are LOINC, UCUM, and SNOMED CT or Applicable Public Health Agency Requirements.

What does this mean? Per the IFR "We do not require Certified EHR Technology to be capable of mapping all laboratory orders or tests to LOINC codes. Rather, we require that Certified EHR Technology be capable of using LOINC codes that are received and retained to populate a patient summary record. Moreover, having LOINC codes used internally for meaningful use Stage 1 will prepare Certified EHR Technology for any future potential meaningful use Stage 2 requirements. We believe the use of LOINC, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), and other vocabulary standards will accelerate the adoption and use of clinical decision support. Requiring LOINC as a vocabulary standard that Certified EHR Technology must have the capability to support for meaningful use Stage 1 provides an incremental approach to achieving these future goals." This is a very reasonable glide path to accelerating adoption of LOINC.

7. Submission to Public Health Agencies for Surveillance

The adopted content standards are HL7 2.3.1 or HL7 2.5.1. The candidate content standards are potentially newer version(s) or standards based on HIT Standards Committee Input, such as CDA documents. Of interest, Geocoded Interoperable Population Summary Exchange (GIPSE), a summary format for surveillance data submission, is listed as a vocabulary standard. I believe it should be moved to the candidate content standards area, as it is a great way to report summary surveillance data content.

The adopted vocabulary standard is listed as According to Applicable Public Health Agency Requirements. The candidate vocabulary standard is listed as GIPSE or According to Applicable Public Health Agency Requirements.

8. Submission to Immunization Registries

The adopted content standards are HL7 2.3.1 or HL7 2.5.1. The candidate content standards are potentially newer version(s) of standards based on HIT Standards Committee Recommendations such as CDA documents. The HIT Standards Committee discussed this, since HL7 2.3.1 is the currently accepted standard for immunization exchange, but HL7 2.5.1 is now ready. Allowing both for now makes sense.

The adopted vocabulary standard is CVX*,+, the CDC's National Center of Immunization and Respiratory Diseases (NCIRD) maintained HL7 code set. Note that this recommendation is marked as not made by either HITSP or the HIT Standards Committee, but actually it was made by both via the HITSP Interoperability Specification for Public Health Case Reporting

The Privacy and Security adopted standards represent the simplest set of technologies and policies that protect confidentiality and ensure data integrity. They are:

1. General Encryption and Decryption of Electronic Health Information - A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256 bit encryption key must be used (e.g., FIPS 197 Advanced Encryption Standard, (AES), Nov 2001).+. This was recommended by the HIT Standards Committee.

2. Encryption and Decryption of Electronic Health Information for Exchange - An encrypted and integrity protected link must be implemented (e.g., TLS, IPv6, IPv4 with IPsec).+ This is a very reasonable recommendation that represents the best thinking of the HIT Standards Committee, HITSP and industry experts. We all recognize that TLS is great for point to point connections, while IPv6 and IPv4 with IPSec are better for organization to organization secure connections. It's a very wise approach.

3. Record Actions Related to Electronic Health Information (i.e., audit log) - The date, time, patient identification (name or number), and user identification (name or number) must be recorded when electronic health information is created, modified, deleted, or printed. An indication of which action(s) occurred must also be recorded (e.g., modification).+ Rather than require ATNA or CT profiles, this recommendation leaves the audit trail to policy - what data to record. This is a reasonable compromise distilled from many hours of expert testimony.

4. Verification that Electronic Health Information has not been Altered in Transit - A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit. The secure hash algorithm used must be SHA- 1 or higher (e.g., Federal Information Processing Standards (FIPS) Publication (PUB) Secure Hash Standard (SHS) FIPS PUB 180-3).+ This was recommended by the HIT Standards Committee.

5. Cross-Enterprise Authentication - Use of a cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails (e.g., IHE Cross Enterprise User Assertion (XUA) with SAML identity assertions).+ Just as with auditing, this is left to policy and does not require a single specific standard/profile such as XUA. The use of SAML approaches does make great sense and will be widely adopted in healthcare, since it is already widely used in other industries.

6. Record Treatment, Payment, and Health Care Operations Disclosures - The date, time, patient identification (name or number), user identification (name or number), and a description of the disclosure must be recorded.+ This too is left to policy, which is a great choice, since the industry has yet to figure out how disclosures will be tracked operationally.

These recommendations are consistent with the work of thousands of experts over the past decade. They do not include all the detailed recommendations from HITSP or implementation profile writers such as IHE but they do include all the highly mature constructs that are deployable in 2011 without over burdening the industry. From what I know about standards harmonization, the state of standards adoption, and the unresolved controversies/debates, the rule is the right mixture of harmonization and compromise. Not every stakeholder will be happy with it, but it is good enough. It moves us all forward toward the goal of less optionality, more constraints, and vocabulary controlled semantic interoperability.

Well done!

My New Year's Resolutions

I've taken a few days off to travel to Southern California for a holiday family get together filled with seasonal celebration, great meals, a few hikes, and helping my parents around the house.

Now that it's New Year's Eve, it's time to reflect on the experiences of the previous 12 months and evaluate changes I can make in my priorities to improve my work, home, and personal lives. 2009 has been a year that required incredible energy just to keep pace with the changes in healthcare IT. Despite my best efforts in 2009, there are areas that need even more energy and focus in 2010.

1. Use all my skills to support EHR change management - it's very clear to me that many clinicians do not want an EHR. Meaningful use is an incentive, but many clinicians remain unconvinced that EHRs will save time, improve safety, and enhance their practices lives. They want to be implemented last in any rollout. Implementing hundreds of clinicians "last" is not doable. My role is to ensure every clinician associated with BIDMC understands the current federal, state, and local EHR activities, aligning incentives and building enthusiasm for EHRs, health information exchange, and quality registries. This means that I'll attend a lot of clinician group meetings and need to ramp up all forms of communication to share updates and experiences with the community.

2. Achieve breakthroughs in web communication tools - 2010 will be the year that we replace the BIDMC intranet, retiring the portal I personally wrote in 1997. 2010 will also be the year that Harvard Medical School moves its external web content to a content management system with distributed authorship. Both these efforts require careful alignment of stakeholders, constant vigilance to ensure alignment of functional requirements with technical capabilities, and active governance committees to serve as a guiding coalition for change. I never want to be so dogmatic that I become an impediment to innovation, so I'll embrace all the Web 2.0 concepts that both BIDMC and Harvard need to make our web sites - intranet and extranet - a very cutting edge experience.

3. Drive community interoperability efforts - The Federal and State environments in 2010 includes many catalysts - meaningful use/standards/certification regulations, ARRA funding (HIE grants, RHITEC grants, Beacon Communities grants, SHARP grants for research, training/education grants), a BIDMC/Boston Public Health Commission/NEHEN pilot to streamline disparities and surveillance reporting, a BIDMC/MAeHC/NEHEN pilot to accelerate community quality metric reporting and several efforts to support bidirectional EHR data exchange through NEHEN, locally implemented RESTful web services (more about these pilots on Monday), and most importantly evolving multi-stakeholder governance through the Eastern Massachusetts Healthcare Initiative, Massachusetts eHealth Institute and our Beacon Communities effort - Greater Boston Aligning Forces for Quality. Clearly 2010 is the year to push interoperability into every practice and hospital.

4. Support my family - Despite all the change around me, I also need to foster stability for those I support - my wife, daughter, and parents. My wife will be evolving her career from teaching to creating more art in her renovated studio and new gallery. My daughter will be applying to college. My parents will be enjoying their new, simpler house which is ideal for a retirement lifestyle. All these folks will need my heavy lifting, encouragement, and emotional support.

5. Renew myself - it's important that I maintain my relevance by adopting new technologies, embracing change, and innovating. Renewal can be technological, philosophical, or personal. The human mind gravitates to new ideas and novel approaches. I want to be at the center of change, inventing it or leading it if possible. I should never be considered a champion of the status quo or an impediment to innovation. How will I renew this year? You can be sure I'll adopt emerging interoperability technologies that accelerate adoption. I'll continue to pilot personal refinements as I've done in 2009 with riding a folding bicycle to all my Boston meetings while wearing experimental Kevlar clothing. I cannot precisely predict the changes of the next year, but when I see transformational possibilities, I will pursue them aggressively.

The common thread of all 5 resolutions is people - aligning incentives for clinicians, empowering staff with new web tools, gaining stakeholder support for interoperability, ensuring the success of my family, and refining my own approach to life. If I can successfully maintain a focus on the people and treat the bits and bytes as secondary, 2010 will be a great year.

Measuring Happiness

It's Christmas Eve and I've put the Blackberry to bed, stopped the strategic planning, and set aside the work of worry.

My daughter does not want to discuss upcoming college tours or the cube root of 127. Instead, we're discussing our personal definitions of happiness.

For my daughter, it's the little things that make her happy. The smiles from her friends, the smell of soy hot chocolate, and the idea of sleeping for 12 hours without homework to do.

For me, I measure happiness by looking at my reflection in the people around me. Have my parents had a good year because of something I've done? Has my wife been empowered to pursue her dreams? Has my daughter gained more self confidence? Do my staff feel good about our trajectory and the stability of their work environment? Do my colleagues feel that I'm a convener who can be trusted to bring people together seeking the greatest good for the greatest number?

Measuring happiness through the eyes of others is imperfect - you cannot make everyone happy. However, you can treat them fairly, positively, and with respect, even if they are naysayers. My metric is to simply ask if I've done my best.

As I sit with my family, a snow covered wreath hanging on my front door (the photo above), the smell of chestnuts drafting through the house, sipping a cup of Graham's 1985 Port and watching The Polar Express, I have a sense that my wife, daughter, parents, friends, staff, and colleagues are achieving their own happiness. I'm at peace with the world and thankful for the year that's passed, happy by all measure.

Happiness to you and to all a good night.

2009 in Review - Part 2

As I've said in my blog about "The Number 5" I tend to organize my life and my projects in groups of 5. My 2009 Review has five segments - Harvard Medical School, State projects, and Federal projects which I presented yesterday plus Beth Israel Deaconess and my personal life which I'll present today.

BIDMC

Beth Israel Deaconess had a turbocharged 2009 which included a new alliance with Atrius Health, numerous new applications, and significant infrastructure improvements.

Community EHR - the first step toward care coordination among all providers associated with BIDMC is to ensure all PCPs, specialists, and referring clinicians have electronic health records. In 2009 we built a data center filled with virtual servers, clustered databases, and software as a service EHR applications fully integrated into our statewide data exchange for administrative transactions, e-prescribing and clinical data sharing. It's a huge change management project as well as a technical one.

Infrastructure - Just as with Harvard, BIDMC experienced explosive growth in the need for storage, especially of medical images. We developed a tiered storage system of SAN, NAS, and Cloud Storage using EMC products. The end result is the right storage platform for the business requirements of the data. We continued to virtualize our servers, cluster our databases, build redundant electrical systems, and ensure business continuance through geographically separated data centers. We elected to move our mainframe to an external hosting facility/vendor - a major transition for us. We enhanced our security capabilities significantly, revised our network architecture for robustness, and upgraded to Exchange 2007, expanding email box size tenfold.

Clinical - We completed our ICU automation efforts, implementing Metavision through all critical care areas including fully electronic documentation and device interfacing. We completed the programming for provider order entry in the NICU and Emergency Department, our last remaining areas with paper orders (both go live in 2010). We implemented electronic Emergency Department documentation, an electronic ED Dashboard at BID-Needham, automated inpatient Oncology management that is fully integrated with our existing outpatient system, pharmacy initiated renewals as part of e-prescribing, results sign off, scanning of the inpatient record, and created a plan for enterprise image management of all modalities over the next year. We enhanced our extranet, redesigned our intranet (goes live in mid 2010), created web-based radiology workflow tools, increased our business intelligence capabilities, and brought new focus to our laboratory information systems project. Interoperability projects linking BIDMC, community providers, patients, government and payers via the NEHEN gateway accelerated and will continue to flourish in 2010 with our Boston Public Health and Community Quality Data Warehouse projects.

Financial - We built numerous additions to our revenue cycle systems preparing for the 5010 and ICD10 conversions ahead. We upgraded all our Peoplesoft platforms to the latest versions, ensuring our customers in HRMS/Payroll, Research, General Financials, and Supply Chain are served with the most modern software available. We enhanced our integration engine capabilities and investigated new platforms to ensure we can provide the connectivity required for meaningful use data exchanges.

These are just a sampling of the hundreds of projects we completed on time and on budget while maintaining 99.9% uptime. I'm very proud of my teams.

Personal

In yesterday's blog, I called 2009 the year of changing everything. In my personal life, it was the year of moving everything.

Last Christmas, I committed to move my parents from the 1970's house where I grew up to a one story, easy to maintain, more modern home. We all accumulate things in our lives and moving requires us to rethink what we own. This year, my parents and my family worked together to streamline the contents of the old house, find a new house, move everything, upgrade the old house, and sell it. A heroic effort by all.

My wife is an artist and she recently expanded her South End (the artsy side of Boston) studio and created the NK Gallery at 460 Harrison, which will open March 1, 2010. This meant that all art, furniture, and supplies had to be moved from our house to the studio and gallery.

My daughter is in the marathon of the High School junior year, getting her life ready for college applications. We'll begin college visits in April. Children grow up fast. She also became an expert archer, averaging over 200 points per round (that's a lot of bull's-eyes from 50 yards away)

This was the year that I maintained every aspect of our 80 year old house - painting the exterior, repairing all screens/storm windows/porch, planing every door, repairing every worn bit of electrical/plumbing/hardware. In addition to being a CIO, I fix toilets!

My federal and state responsibilities, especially ARRA, reduced my free time and I did little rock/ice climbing in 2009. However, I was able to hike in New Hampshire, Japan, and the Eastern Sierra, as well as my usual kayaking, biking, and nordic skiing, so I've stayed in reasonable shape.

During 2009 I was able to maintain my daily writing for my blog, my Computerworld columns, and several journal articles. I practiced the Japanese Flute every weekend to clear my mind.

As I end 2009, BIDMC projects are on track and there are governance processes in place to ensure our resources are well aligned with customer needs. My family, my home, my outdoor activities, my writing, and my flute playing seem in good shape.

I look forward to everything 2010 will bring - the final regulations for meaningful use and certification, the HIE/RHITEC/Beacon Communities grants, and acceleration of healthcare IT in every practice setting. Hard work is fine as long as it's predictable. I'm hopeful that 2010 will be more consistent than 2009. Then again, I'm the eternal optimist!

2009 in Review - Part 1

As I look back on 2009, it was a year of incredible change.

I'll post this in two parts. The first includes Harvard Medical School and State/Federal work. The second will cover BIDMC.

Harvard Medical School

Infrastructure - demand for storage increased 250%. Willingness to pay fell below $1/gigabyte. We installed 200 Terabytes of Isilon clusters for the research community. Power and cooling became real issues in our data center. We virtualized everything possible, retired legacy equipment and began using special cooling techniques for our high performance computing clusters. Network speed and reliability demands increased so we built a redundant network core and enhanced Gig to the desktop support. We gave everyone a 1 gigabyte mailbox. Security investments increased substantially.

Research - Demand for high performance computing increased dramatically. We grew our central cluster resources and software capabilities to over 1000 cores. We enhanced desktop service and offered additional security tools to ensure compliance with federal and state laws.

Administration - Workflow became increasingly important and we implemented document management and office automation tools. Business intelligence demands increased significantly and we added datamarts and web-based reports.

Education - We added inline grading, enhanced mobile offerings (Kindle, iPod Touch/iPhone) , new video infrastructure, and online collaboration tools. We built faculty disclosure of conflict of interest on the web. Increasingly, virtual microscopy using Aperio software has replaced the use of slides and oil. Demand for video and web conferencing has grown substantially and we've deployed WebEx, Adobe Connect, and real time video multicast.

CTO- Novel social networking tools in support of research became a real driver throughout Harvard Medical School.

NEHEN/State projects

The New England Health Exchange Network merged with MA-Share to create a single healthcare information exchange with a single governance for the state. A commitment to exchange data from the CEOs of the payers and providers in Eastern Massachusetts, Meaningful Use, the HIE grants, and Beacon Communities grants have created new momentum to share data among payers, providers, and patients. 2010 should be the tipping point for rapidly accelerating widespread data exchange in the state.

HITSP/HIT Standards/Federal

HITSP and its tiger teams moved from use cases to Service Collaborations/Capabilities to support the American Recovery and Reinvestment Act. The HIT Standards Committee made standards recommendations to ONC in support of certification and meaningful use. The HIT Standards Committee developed a great camaraderie among its members that promoted lively, multi-stakeholder discussion. Transparency ruled and no subject was awkward to discuss.

Summarizing these three facets of my life - 2009 represented a significant expansion of Harvard Medical School infrastructure and applications, a new momentum for statewide health information exchange via NEHEN, and convergence on standards leading to new regulations guided by completely new Federal priorities.

Not quite the year of living dangerously, but definitely the year of changing everything!

The December HIT Standards Committee meeting

The December meeting of the HIT Standards Committee was a conference call, open to the public, as are all HIT Standards Committee meetings. We discussed four major topics -

*A summary of the security standards recommended thus far and lessons learned from the security issues hearing

*Next steps for the Clinical Operations Task Force on Vocabulary

*An update on the Implementation Workgroup

*A report from the HIT Policy Committee NHIN workgroup

Dixie Baker's excellent discussion of the security standards approved thus far illustrated that they are very manageable and are mostly in widespread use today, so 2011 does not represent a huge barrier for implementers.

Comments from committee members include (note that no changes in recommendations were made at this time)

Rather than mandate a standard for an organizational audit registry (ATNA), instead use Policy to require a list of data elements such as ASTM E2147 to be reported on request

Rather than require the IHE Consistent Time profile, instead specify basic NTP/SNTP (with the time server stratum determined by policy)

Do not require XDS/XDM/XCA/XDR as transport standards.

Do note require CDA as the metadata header for unstructured data such as PDF, TIFF, and CCR.

Allow IPsec with either IPv4 or IPv6 for securing the NHIN "backbone"

Use X.509 for authenticating NHIN nodes

Use TLS for securing transactions that require more finely grained controls than IPsec provides such as authentication of, and secured path to, servers or applications within an organization

When the interim final rule is issued, many public comments will follow and the HIT Standards Committee will consider the public comments and comments of the Committee members to generate its final recommendations to ONC.

The Task Force on Vocabulary discussed those code sets and value sets that would accelerate interoperability such as a universal lab compendium that covers the majority of ordered tests, a SNOMED-CT subset for problem lists, and mappings from SNOMED-CT to ICD and CPT. There is little controversy about vocabularies - everyone on the committee agrees on the need for publicly available code sets and value sets.

The Implementation Workgroup continues to emphasize its mantra - keep standards as simple for the user as possible.

The HIT Policy Committee NHIN Workgroup presented it's early priorities - focus on Push transactions while maintain a vision for widespread use of Pull transactions eventually.

A very productive and positive meeting. Our next steps are to review the comments from the Interim Final Rule which we anticipate being published on or before 12/31/09.

Cool Technology of the Week

I recently wrote a Computerworld Column about Email Overload.

I'm a data oriented guy and was curious to learn detailed statistics about my own Blackberry use.

A found a great Blackberry application called "I Love Blackberry" from EarlySail.

Here's my Blackberry statistics:

Average Daily - 111 Times for 2 hours 24 minutes divided as 86 times for 1 hour 34 minutes during work hours and 25 times for 50 minutes outside of work hours.

Average Weekly - 482 Times for 9 hours 31 minutes divided as 431 times for 7 hours 50 minutes during work hours and 51 times for 1 hour 40 minutes outside of work hours.

This means that I spend approximately 20% of my work time doing Blackberry communications. A startling statistic.

Between work time, home time and driving time email has added 20-25% more work to my week. I am more productive, and resolve issues sooner, and I can run organizations remotely. The EarlySail applications provides great insight into the time and effort cost of maintaining this level of connectedness.

That's cool!

My Life as a Nerd

As a teen, I was awkward, a social outcast, and more focused on math, science, and engineering than sex, drugs, and rock&roll.

In 1972, I won the 4th grade science fair by building a Van de Graaff generator- the photo above. Few people know that it failed as the judges were about to review it. I noticed the power supply leads were loose and thinking I had unplugged the 4000 volt transformer, I tightened them with both hands. Whoops - 4000 volts surged through my body and knocked me across the room. My hair has been curly ever since.

Also in 1972, I received my first electronics breadboard set - the 65 in 1 Electronic Project Kit.

I taught myself how to use PNP and NPN transistors, how to use resistors/capacitors/inductors, and the basics of analog to digital conversion. Here's my December 25, 1972 picture- note the short sleeve shirt, buttoned at the top button, the white socks, and the black horn-rimmmed glasses. I was too young for a pocket protector - that came later.

Today, my CIO life is filled with glamor, thrills, and chills. From nerd to IT Buckaroo Bonzai. Geeks of the world unite!

Creating Interoperability with Atrius Health

Today, BIDMC and Atrius Health officially celebrate their collaboration - bringing together a large multi-speciality practice group with an academic teaching hospital for coordination of care, a focus on quality, and improvements in efficiency. IT is a major component of our work together. Here's what we've done:

*Any admissions to BIDMC result in automated electronic notification of Atrius PCPs

*Any ED discharges result in automated electronic care summaries sent to Atrius PCPs

*Any inpatient discharges result in automated electronic care summaries including medication data for reconciliation sent to Atrius PCPs

*All email between the two organizations is secured via TLS and is HIPAA compliant

*All BIDMC clinical data is viewable within Epic without the need for a separate username/password or the need to respecify the patient. We do this via RESTful protocols that transmit patient context, login credentials and access control information between Epic and BIDMC systems.

*All Atrius data is viewable to BIDMC clinicians via Citrix. Over the next year, we'll implement more automated methods following the standards that support meaningful use data exchanges.

*We've created a web-based automated census of all admitted Atrius patients including those in ED or hospital observation beds (pictured above)

*Atrius Case Management staff have full access to all BIDMC clinical systems

*BIDMC has provided all phones, networks (wired/wireless), desktop, printers, and seamless LAN to LAN VPN access linking the BIDMC and Atrius networks.

We've done all this over 60 days and have learned a great deal. The Atrius BIDMC relationship will be a great testbed for interoperability activities in our Healthcare Information Exchange and Beacon Community work.

Learning Management Systems

Every day in my hospital life there is a new training or a new compliance requirement. Competencies and skills need to be refreshed, certifications updated, and new ideas disseminated.

To date, we've done this in a multitude of ways

A self built training system which presents PDFs or Powerpoints followed by online questions that are scored and stored electronically for use in certification processes.

A self built survey system which can be used to gather basic information from electronic forms.

A Peoplesoft HRMS system which stores data about employees

A Residency system which tracks Resident credentials, duty hours, and immunizations.

Ideally, we simplify all our competency documentation, training, and compliance in one (or a small few systems). Some of our requirements include

Training - Safety, Clinical

Compliance - HIPAA, Conflict of Interest

HR - Evaluation/Annual Review to ensure completion of institutional requirements, orientation, license, credentials

Health - flu tracking, TB testing

To begin the process, we established a steering committee and built a guiding coalition of stakeholders to move this forward. Here's the powerpoint we presented to them today.

Our next step is to write an RFP and explore vendor options.

I'll let you know what we decide.

A BIDMC Progress Report on Interoperability

Like many complex healthcare systems, BIDMC does not have a one size fits all solution for ambulatory records. Although we favor integrated systems, we need to achieve interoperability via interfaces between two EHRs - a home built web-based product called webOMR and a commercial hosted version of eClinicalWorks.

Prioritizing our interoperability efforts to improve clinician workflow, enhance the quality of care delivered, and adhere to multiple federal and state initiatives requires extensive planning with many stakeholders. Here is our vision:

In January of 2010, the Federal Notice of Proposed Rulemaking on Meaningful Use will outline the data exchanges we must perform and the timeline to perform them. The 2011 exchanges are anticipated to be

Lab results delivery (true integration)

ePrescribing

Claims and eligibility checking

Quality & immunization reporting

Registry reporting and reporting to public health

Health summaries for continuity of care

Populate PHRs

Here's our plan.

webOMR is an integrated system which is perfect for clinicians who order all their laboratories and radiology tests from BIDMC. It is not ideal for community clinicians with limited BIDMC interactions. For BIDMC-centric practices, lab results are already truly integrated with BIDMC lab. e-Prescribing is already live. Claims/eligibility/administration transactions are already live. We have begun a $500,000 Quality Registry reporting project, and have committed to a Boston Public Health Commission Public Health Reporting project. We will implement immunization registry reporting once a public entity is able to receive such data. We have already integrated webOMR into our tethered PHR (Patientsite), Google Health, and Microsoft Healthvault. We have already built outbound BIDMC discharge worksheets into eCW. We have already made webOMR data viewable inside eCW via the Magic Button pop up viewer. What remains to be done is that currently webOMR has no way to view eCW patient summaries.

eCW is a commercial EHR which is perfect for community clinicians who need to interact with non-BIDMC hospitals. eCW has already been integrated with Quest and soon with Needham. It is capable of receiving other lab feeds such as Milton or Caritas, as soon as those organizations provide outbound interfaces. e-Prescribing is already live. Claims/eligibility/administration transactions are already live. We have begun a $500,000 Quality Registry reporting project. We will implement immunization registry reporting once a public entity is able to receive such data. eCW has a patient portal that will go live in Spring 2010. We have already enabled eCW to receive clinical summaries from outside EHRs. What remains to be done? There is not a current timeline to interface eCW to public health reporting, but this must be done by 2011 if the public health entity is able to receive such data. There is not a current timeline to send clinical summaries between eCW and webOMR, but this also must be done by 2011.

Our next planning priority is to work with stakeholders to define the workflow and process needed to exchange eCW clinical summaries with webOMR. We will then meet with eCW to determine how to achieve this technically.

Thus, as you can see, we achieved a degree of interoperability that meets meaningful use criteria. We commit to have a plan and timeline in place for eCW to webOMR clinician summary transmission to complete our interoperability efforts. Will it meet all clinician needs? Many of them. Will it meet all their expectations? Probably not. We are still years away from being able to exchange the entire medical record between systems in the same way we can transport our cell phone numbers between carriers. It will be a journey. We'll start with the meaningful use transactions. We'll move from unstructured to vocabulary controlled structured data elements. True "end to end" point of origin to point of use interoperability across different EHRs will take years. I will do my best to educate our clinicians and move us forward continuously toward the nirvana of complete interoperability they seek.

Cool Technology of the Week

Have you ever been tempted to read your email while driving? In Brookline, it's already illegal and in Boston we may soon see new restrictions.

DriveSafe.ly is a mobile application that reads text (SMS) messages and emails aloud in real time and automatically responds without touching the mobile phone. It's available for Blackberry, iPhone, Android, and Windows Mobile.

The free version reads the first 25 words of the message in a female voice and offers an optional text/email auto-responder such as "I'm driving right now but will followup when I arrive at my destination"

The $13.95 version grants a license for the lifetime of the phone, reads the first 500 words of each message, offers a selection of voices, and includes the same autoresponder.

I installed the application wirelessly on my Blackberry Bold (it appears in the Downloads folder) and activated the service. Each incoming email is automatically read aloud without touching the device. You can manually select an email or message to be re-read if needed.

The performance was great - a few seconds via 3G AT&T service to upload each mail message, convert text to speech and play the audio message. Since it happens automatically, there is no need to pick up your mobile device while driving ever again.

You can drive safely and still stay in touch. That's cool!

A Clothing Experiment

I'm a big fan of self-experimentation. I have an RFID implant.

I've had my genome sequenced and publicly released.

This winter, I'm testing a business suit made from Gortex and Kevlar. Why not wear the same clothing to Board meetings that I'd wear on Mt. Washington?

Gortex is expensive. Arcteryx gear is expensive. However, if the suit is the modern equivalent of the Man in the White Suit - waterproof, windproof, stain proof and essentially indestructible, it may be the last suit I will ever buy.

Today, I road my bike in a Boston blizzard, below freezing, to 7 meetings in 5 locations, wearing nothing but my suit. I arrived at each meeting warm and dry.

Here are the specifics of what I wore

Vegetarian Shoes Chelsea Vegan boots size 10

Arcteryx Veilance Blazer size 42 (Gortex)

Arcteryx Veilance Stealth Shirt size Medium (Kevlar)

Arcteryx Veilance Stealth Pants size 32 (Schoeller)

in rain, sleet, snow, and gale force winds, arriving at my meetings like it was a Summer day.

The purchase was an early Christmas gift from my wife and although it was quite expensive, I suspect the cost per day will be less than Brooks Brothers, given the longevity and utility of the materials. A very successful experiment thus far.

Advice to Beacon Communities

On December 2, David Blumenthal announced the $235 million dollar Beacon Community Program to accelerate and demonstrate the ability of health IT to transform local health care systems.

As we all think about how best to submit our applications (15 communities will be chosen), here are a few guiding principles:

1. This must be a public/private partnership - we need to ensure the "public good" needs of population health reporting, disparities in care reporting, immunization registries, administrative simplification, and biosurveillance are met. We must ensure private practice needs to achieve meaningful use are considered including electronic lab workflow, e-prescribing, and clinical summary exchange. We must include payers, both public and private.

2. We need to leverage the work that has already been done. In the case of Massachusetts we have multiple organization such as

Massachusetts eHealth Collaborative - implements EHRs

New England Healthcare Exchange Network - exchanges healthcare data

Massachusetts Health Data Consortium - develops healthcare IT policy and educates the community

Eastern Massachusetts Healthcare Initiative - provides a guiding coalition of payer and provider CEOs

Massachusetts eHealth Institute - the state organization serving as the distribution point for Federal funds

Massachusetts Health Quality Partners - the quality analysis organization

Boston Public Health Commission - the public health reporting entity

All of these organizations need to work together to create a single Beacon Community application. Having multiple applications from a region purely because of political infighting does not telegraph the kind of collaboration needed to be a beacon for others.

3. The focus must be on quality and efficiency, not IT for the sake of IT. There must be a measurable outcome - better wellness, fewer strokes/cardiac events, less hospitalizations.

4. There must be great governance - a steering committee and a series of working groups that can make tough decisions on detailed issues.

5. The strategy should be easily understood by all i.e. 40% of all clinicians in our community will have certified EHRs that are meaningfully used and exchanging data with other providers, payers, and patients for coordination of care and quality improvement. We will create the foundation for healthcare reform in which organizations are held accountable and rewarded for patient wellness, not delivering more fee for service care.

Thus, gather your stakeholders, creating a collaboration and ensure that IT raises the bar for everyone. Closed and proprietary IT is no longer a strategy, since healthcare is a zero sum game balancing the interests of employers, payers, and providers in the service of the patient.

Advice to Health Information Exchanges

With the HIE grants around the corner, many communities are asking me for advice to prioritize their local/regional infrastructure and applications. Here are my recommendations based on leading an HIE for the past 10 years.

1. Define your business requirements based on the value proposition for participants. This will maximize the likelihood stakeholders will pay for the services they receive, ideally based on gainsharing a portion of their cost avoidance i.e. if a lab costs $1.00 to send via email and .20 to send via the HIE, the hospital can pocket .80 and everyone wins.

2. Ensure you have a business model - subscription-based is good, since grants are not a business model. Transaction fees are an impediment to commerce - they are a disincentive to using the HIE. A fixed subscription fee encourages maximal use of the HIE.

3. Ensure you have policies for consent, auditing, and authorization of trading partners. Policies constrain technology choices and ensure the exchange is trusted.

4. Start with Push transactions. This is a very important point. I've written several blogs about the importance of using the simplest possible standards to achieve the business goal. A RESTful approach which enables clinical data to be pushed from one clinician to another is simple to implement since it leverages existing standards and capabilities of web servers without requiring mastery of more complex techniques. In Massachusetts we push admission notification, discharge summaries, ED summaries and other CDA documents. We're currently implementing push of quality data to registries and public health surveillance to the Boston Public Health Commission. The advantage of Push is that it does not require a master patient index, since the messaging is provider to provider or organization to organization. Consent is easy since the patient simply consents for the push. Wes Rishel has written several great blogs about this approach, which are important to read as they reflect some of the discussion in the HIT Policy Committee's NHIN Working Group.

5. Have a vision for Pull transactions. At some point, the usual ED use case will be mentioned - how do you pull together the entire history of patient from all the sites they have received care in a community? You'll need a master patient index, a record locator service (what institutions have records on the patient) and a means to pull summaries from each site. This pull infrastructure is much more complicated and expensive. Consent is much more complex - who can pull what from where and when? Instead of a provider to provider push involving two clinicians, pull could result in hundreds of people viewing a record. Push is great, but it really does not help the Emergency Department gather data about a patient for life saving treatment. Eventually we'll need to implement Pull.

As I've said in my blog about the Genius of the AND - the right approach is Pull and Push - REST and SOAP.

In the upcoming weeks, we'll have the interim final rule on standards. In the upcoming months the NHIN Working Group will provide us with policy guidance. The 5 points above plus the work of the HIT Policy/HIT Standards Community should provide the guidance that HIEs need.

Consistent Time

I was recently asked by my staff how we should coordinate the time of day across organizations which exchange healthcare information. In a future which treats data from outside data sources as appropriate for clinical decisionmaking, you can imagine the following data exchange:

Hospital 1 posts lab result 12:01pm

Hospital 1 sends result to Hospital 2 12:02pm

Hospital 1 revises lab result 12:15pm

Hospital 1 sends revision to Hospital 2 12:16pm

Order is entered at hospital 2 12:17pm

Time synchronization among participants in a healthcare information exchange is important. If Hospital 2's clocks were 3 minutes slow, it would be challenging to know if the order was entered based on the original or revised lab result.

HITSP has published T16, the Consistent Time Transaction to help address this problem. It's based on an IHE profile created to support the synchronization of security audit logs.

It uses the Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP).

Here is the relevant section IHE ITI TF Vol 2: 3.1.4.1 from IHE-CT profile

"The NTP transactions are described in detail in RFC1305. There is also extensive documentation on the transactions and recommendations on configurations and setup provided at http://www.ntp.org. Rather than reproduce all of that material as part of this Framework, readers are strongly encouraged to explore that site. The most common mode is the query-response mode that is described below. For other forms, see RFC1305 and the material on http://www.ntp.org.

The Time Server shall support NTP (which implicitly means that SNTP clients are also supported). Secure NTP may also be supported. The Time Client shall utilize NTP when it is grouped with a Time Server, or when high accuracy is required. For ungrouped Time Clients with 1 second accuracy requirements, SNTP may be useable. Time Clients may also support Secure NTP."

Although original designed for audit trails, the transaction has been expanded to other transactions, since organizations have realized that having synchronized clocks really helps documentation integrity and workflows. As the use of the consistent time is extended beyond audit trails, there are interesting issues about just how precisely synchronized devices in a network should be - a few seconds, one second, a subsecond?

At BIDMC, we point to stratum 1 servers that are directly connected to computers attached to atomic clocks.

The interesting question for HIEs is what should be synchronized.

My hospital servers are all synchronized against one set of time sources.

Our HIE, NEHEN, has suggested that all the gateways used to exchange data among multiple hospitals should be synchronized with one time source to ensure that all send and receive timestamps for clinical data exchange are consistent. Otherwise, data might arrive at one hospital before it leaves another!

However, since HIE gateways will be synchronized with one time source and hospital internal servers may be synchronized with others, the HIE time may vary from the hospital time.

Maybe the right answer is that as part of our national healthcare IT effort, we should mandate that all hospitals and HIEs should use a single set of known-adequate time servers to ensure all healthcare time is consistent.

For the moment, the following strategy seems reasonable

1. Require hospitals use NTP to ensure their internal time stamps are consistent. This will ensure audit trails within an organization, whether merged in an audit repository or just reported from disparate systems upon request, are consistent.

2. Synchronize health information exchange gateways within an HIE to a single time source so that transactions have consistent send and receive times.

If we know the hospital audit trail time stamp is consistent and we know the HIE send/receive times are consistent, we can recreate any event that is disputed.

Expecting every hospital to change its time synchronization servers to those used by the HIE is unrealistic - what if the hospital participates in multiple HIEs?

At some future time, we all may change to a national healthcare time server that is part of the NHIN, but for now the hospital use of NTP will be decoupled from the HIE use of NTP.

Cool Technology of the Week

In June, I bought a Strida folding bike and change my commute pattern so that I park outside of town and cycle to all my meetings.

Now that the days are shorter, I'm cycling in twilight and I needed a set of lights for visibility. I chose the Knog Frog Lights from Australia.

These lights are water-resistant, weigh 12 grams, burn for 160 hours on 2 coin cells, and have a flexible silicon body with an integrated clipping/quick-release mounting. The 10,000 millicandela LED is visible up to 600 meters. I purchased a white light for my handlebars and a red light for my seatpost. I push on the silicon housing and set them to flashing mode at dusk.

They've been a great addition to my Strida and keep me safe in Boston traffic.

2 bike lights burning for 160 hours that weigh under an ounce. That's cool!

My Christmas List

As I prepare the list of the few gifts I want for Christmas, I'm guided by first principles. Here's a great column that reflects on what we have and what we keep. Know what you own and ensure it's the minimal right stuff .

For me, there are only two items on my Christmas list
- A small home workbench that enables me to help my family with electrical, plumbing, carpentry and painting projects.
- A bike repair stand that attaches to the workbench so that I can maintain the gears, cables, and components of my family's bikes.

As stated in the column above, I try to own little, but if there are tools I use every day, I try to own the right ones. My personal tools are all Craftsman and my bike maintenance equipment is from Park Tool.

The good news about being very limited and precise with your belongings is that there are no impulse buys, no Black Fridays and no shopping stress, just a plan.

I plan to buy them online with Sears and REI gift cards, then assemble them on the weekend after Christmas.

Strong Identity Management

In addition to audit trails, a key component of enforcing security policy is ensuring the identity of those who use applications. In the November 19th HIT Standards Committee testimony, we heard about the need for strong identity management.

Currently, most systems support username/password with various rules such as those we use as BIDMC:

Passwords must be at least eight (8) characters in length

Passwords must contain characters from at least three (3) of the following four (4) classes:

English upper case letters A,B,C,...Z

English lower case letters a,b,c,...z

Westernized Arabic numerals 0,1,2,...9

Non-alphanumeric ("special characters") such as punctuation symbols: !,@,#...

New passwords must be different from previously used passwords.

Under no circumstances should the Passwords contain your username or any part of your full name or other easily identifiable information.

However, it's clear that something stronger than a username/password will be needed for e-prescribing controlled substances. The DEA has insisted upon NIST Level 3 authentication. What do levels of authentication mean?

Level 1 is the lowest assurance and Level 4 is the highest. The levels are based on the degree of confidence needed in the process used to establish identity and in the proper use of the established credentials.

Level 1 - Little or no confidence in the asserted identity’s validity. Level 1 requires little or no confidence in the asserted identity. No identity proofing is required at this level, but the authentication mechanism should provide some assurance that the same claimant is accessing the protected transaction or data.

Level 2 - Some confidence in the asserted identity’s validity. Level 2 requires confidence that the asserted identity is accurate. Level 2 provides for single-factor remote network authentication, including identity-proofing requirements for presentation of identifying materials or information.

Level 3 - High confidence in the asserted identity’s validity. Level 3 is appropriate for transactions that need high confidence in the accuracy of the asserted identity. Level 3 provides multifactor remote network authentication.

Level 4 - Very high confidence in the asserted identity’s valid. Level 4 is for transactions that need very high confidence in the accuracy of the asserted identity. Level 4 provides the highest practical assurance of remote network authentication. Authentication is based on proof of possession of a key through a cryptographic protocol.

If Level 3 authentication is implemented in healthcare for prescribing controlled substances, strong identity management may be expanded to other aspects of healthcare such as signing notes, signing orders, or gaining physical access to restricted areas.

Given the workflow implications of an added authentication burden, it's important to choose the right technology approach.

There are a wide range of two-factor authentication methods, including security tokens, smart cards, biometrics, certificates, soft tokens, and cell phone-based approaches.

I've had experience with each of these. Here's a summary of my findings

Tokens - you'd think tokens would easy to use, but we had a high login failure rate, challenges with tokens getting lost/destroyed (in the laundry), time synchronization issues (as the battery begins to age, the clock inside the token may begin running slowly), and clinician dissatisfaction with having to carry yet another device. A clinician with multiple affiliations has an even worse problem - multiple tokens to carry around. Token and licensing costs were expensive.

Smart cards - we use smart cards for physical access and they work well. They are foolproof to use, can be laundered without an issue, and are inexpensive. The only problem with using them in software authentication is the expense of adding smart card readers to our 8000 workstations. Buying and maintaining 8000 USB devices is costly. However, they are still a serious consideration, since clinicians like the idea of walking up to a device and using something they already have - a badge - to authenticate.

Biometrics - I've written about our use of BIO-key in the Emergency Department. Biometrics are convenient because you can just swipe a finger, which you always have with you (we hope). Many laptops have built in finger print readers and the BIO-key software easily integrates web applications into Active Directory. As with smart cards, the only challenge is installing and maintaining fingerprint scanners on 8000 existing desktops. Biometrics have been very popular with our clinicians and we've had a very low false negative rate (and zero false positives).

Certificates - managing certificates for 20,000 users is painful. We've done it and although I am a strong believer in organization level certificates, I remain unconvinced that user level certificates are a good idea. Maybe new approaches like Microsoft's Infocard, which presents digitally signed XML-based credentials, will make storage and presentation of cryptographic credentials easier.

Soft tokens are just a software version of hardware token running on a mobile device or desktop. Since software must be installed and maintained on each device, they can be a challenge to support.

Cell phone based approaches - Harvard Medical School recently implemented two factor authentication with cell phones as a way of securing password reset functions. It's been popular, easy to support, and very low cost. Companies such as Anakam offer tools and technology to implement strong identify management in cell phones via text messaging, voice delivery of a PIN, or voice biometric verification. Per the Anakam website, their products achieve full compliance with NIST Level 3, are scalable to millions of users, cost less than hard tokens or smart codes, are installable in the enterprise without added client hardware/software, and are easy to use (all you have to do is answer a phone call or read a text message).

Thus, my vote for achieving NIST Level 3 is to chose among smart cards, biometrics or cell phone based approaches depending on the problem to be solved and the workflow that is being automated. Although we've not yet implemented cell phone approaches for EHR authentication, I can imagine that our 2011 authentication strategy might be

Physical Access (hundreds of existing doors that have smart card readers) - Smart cards

Fast trusted login in the Emergency Department (100 devices that are kept in a closed physical space) - Biometrics

Generalized two factor authentication for e-prescribing controlled substances (thousands of devices and hundreds of users) - Cell phone approaches

With strong identity management, our audit trails will have greater value. It will be challenging for a user to claim that they were not the person performing the transaction. The combination of trusted identity and complete audit trails is key to a multi-layered defense against privacy breeches.

Standardizing Audit Trails

Over the past month, the HIT Standards Committee and its Privacy and Security Workgroup have discussed the simplest set of security standards for 2011 and beyond.

We've had debates about audit trails, strong identity management, and consistent time. Each of these topics deserves its own entry and I'll start with audit trails. Thanks to John Moehrke of GE for background information - he was part of the team that wrote the IHE profile on auditing, ATNA, which is based on ASTM E2147 healthcare specific audit trail standards.

What is an audit trail and how does it differ from a disclosure log?

Audit is simply a record of system events -- it does not get into "why" as does accounting for disclosures (which includes release of information to external organizations for a specific purpose). HIPAA requires that organizations:

1. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information; and

2. Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

The first HIPAA requirement is what should be captured in the EHR product certification criteria, and the second is a "meaningful use" policy statement. While the ATNA profile draws upon the ASTM E2147 standard in its specification of the data elements to be captured in an audit trail, it goes beyond what either ASTM or HIPAA require in its focus on the concept of centralizing audit information by having multiple systems send audit messages to an audit repository. The ASTM standard specifies the data elements to be captured when auditing accesses to protected healthcare information, but goes beyond ATNA by also specifying a list of data elements to be included in an accounting of disclosures.

The issue with audit trail standards is determining how specific to be about their requirements. Technical requirements for auditing accesses in EHR systems, from most restrictive/intrusive to least could be:

1. Cross-enterprise ATNA - the ability of an organization in a health information exchange to query another organization's audit trail. This is helpful in maintaining trust because there is a virtual audit trail for the community.

2. Intra-enterprise audit integration - the capability to construct a continuous audit trail across systems within an organization using ATNA (such as the Veteran's Administration Auditing Service project.

3. The first HIPAA requirement above, which is a policy "standard" not a technological one.

Initially, we debated the need for cross-enterprise audit trails. Shouldn't ARRA privacy requirements be met with just #3, a policy?

In our Security Testimony on November 19th, we heard that availability of audit trails between organizations is one of the most important elements of building trust in a health information exchange.

Automating audit trails at the organizational level, #2, seems like a wonderful solution to security, breach notification, and privacy. There have been very public exposures of health data, and in each case the people who violated privacy were discovered through the use of audit logs:

Health Data Management

Modern Healthcare

The Register

University of Iowa

Arkansas Online

There are more…

When it comes to real world implementation of audit logs, I know there is a big difference between legacy software and new applications. Typically EHRs have built up audit logging incrementally, based on customer requests, not via foundational design. Ideally, audit logging would have been architected to be a replaceable code module or web service, but this is not likely in existing applications. However, Healthcare Information Exchange/NHIN is largely a greenfield. This is new code that could be held to higher standards.

Thus, one possibility is to use #3 (a policy) for organization level audit trails, but to use a standards based audit repository (ATNA) for Health Information Exchanges. For internal security events it could be acceptable to record audit logs in a proprietary format as long as they can be exportable into a text file format with a well formed time-stamp.

We'll be having an ongoing dialog about this topic over the next month. I welcome your input.