EHR for Non-Owned clinicians - Coming to terms

Since our community EHR infrastructure is now built we're in an education and communication phase, explaining to clinicians what it does, what it costs, and what they can expect. All our written and verbal communication must be consistent to ensure we set the right expectations. Part of being accurate is a precise definitions of our terms - what is an EMR, EHR, PHR, HIE, RHIO etc. The consensus definition work of NAHIT and AHIMA was presented to AHIC last week. Although not everyone will agree with these definitions, they are starting point. At AHIC one public comment illustrated the problem of legacy definitions - NextGen markets its product as the NextGen EMR. Does that mean it is inferior to the eClinicalWorks EHR, since an EHR is defined as standards-based and interoperable, while an EMR is defined as a single institution's standalone record. At BIDMC, we're providing a community EHR, we have an institutional EHR called webOMR (Online Medical Record), and a PHR called Patientsite. Patientsite is fully interactive with multiple data sources and Google Health, so we can continue to call it a PHR per the definition below. Here's the summary of the NAHIT work:

Electronic Medical Record
An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one health care organization.

Electronic Health Record
An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff, across more than one health care organization.

Personal Health Record
An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.

Health Information Exchange
The electronic movement of health-related information among organizations according to nationally recognized standards. HIE is a verb describing a process.

Health Information Organization
An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards. HIO is a noun describing an organization.

Regional Health Information Organization
A health information organization that brings together health care stakeholders within a defined geographic area and governs health information exchange among them for the purpose of improving health and care in that community

Next week's entry about our non-owned clinician project will provide an overview of our Health Information Exchange activities.

Aligning Clinicians and IT

Each year when I publish the IT operating plan summary, I'm careful to relate the projects to their strategic importance, impact on patients, improvements in quality/safety, and return on investment.

This was nicely stated by Ian Furst who commented on my blog about Marketing IT. He noted that a statement such as "Our goal is to be 100% computerized by 2009" sounds like an IT goal. Ideally, goals should start with "we will improve the patient care/experience/life expectancy with....."

To align Clinicians and IT, I have a Clinical Information Systems Steering Committee which includes membership from 11 subcommittees:

Chair of the Laboratory Information Systems Committee
Chair of Radiology Information Systems Committee
Chair of Critical Care Information Systems Committee
Chair of Inpatient Information Systems Committee
Chair of Ambulatory Information Systems Committee
Chair of Health Information Management Committee
Chair of Community Information Systems Committee
Chair of Decision Support Information Systems Committee
Chair of Revenue Cycle Information Systems Committee
Medical Executive Committee Representative
Operating Room Executive Committee Representative

The work of all these committees was recently presented to the Clinical Operations Coordinating Committee, the joint administrative/clinician governance of BIDMC. The presentation I used illustrates the major clinical accomplishments for FY08, the goals for FY09 and plan for future years. Each slide describes the clinical benefit of the projects.

When I execute complex clinical projects each year, I'm typically asked three questions about my approach to aligning clinicians and IT.

What are our biggest challenges running large clinical information systems projects?

Every project must start with a charter that identifies the stakeholders, roles/responsibilities, the purpose of the project, the milestones, and metrics for success. The only way to balance scope, timing, and resources is to have an unambiguous definition of who cares about the project, who does the work, why the project will be done, when the project will be done, and how project success is defined. As the project proceeds there will be many requests to expand its scope, add more features, increase the number interfaces, and expand the the stakeholder population being served. The committee providing governance to the project, guided by the charter, must resist the change in scope. If change in scope is deemed critical to the project's success then the charter should be changed to reflect the impact on project timing and resources, ensuring that change is broadly communicated.

What are the biggest mistakes?

Projects must ultimately be driven by their business owners, such as the doctors, nurses and staff who will be using the finished system, not by IT. Having clinician driven projects ensures the application becomes "the clinician's system" and not the "IT system which administration forced on us". Also, software should not be used to change workflow. Before implementation of the software, business processes should be optimized and workflow documented. Then, software can automate that workflow. If software is used to force behavioral change, clinicians will blame the software for any frustrations they have about the process change.

What are the top 3 best practices to ensure success?

Big bang IT never works. Pilots and phased implementation of applications reduces the risk of failure and ensures the resources are available to respond to any infrastructure or application issues which occur during roll out.

Broadly communicating the benefits of the project and the urgency to implement it really helps with clinician acceptance/adoption.

Project management is key. Ensuring the scope is constrained, milestones achieved, and participants coordinated are prerequisites to a successful project.


As a clinician myself, I use the systems we create. Being a physician CIO/CMIO helps me understand the clinical impact of every project, engage the clinicians in every project, and establish trust with all the doctors and nurses in the hospital.

Cool Technology of the Week

On May 29, 2008, Harvard received a $117.5 million dollar Clinical and Translational Science Award to seamlessly link together all the Harvard hospitals and research community.

By July 1, 2008, we'll pilot the tools and technologies needed to make this happen.

What will we launch on that date? Call it Facebook meets eHarmony for the Harvard community.

The Catalyst portal brings together numerous federated databases at Harvard into a new social networking application. It's the Cool Technology of the Week and here's how it works.

Harvard has a basic faculty database that includes information about every faculty member, such as their title, institutional affiliation, and email address. We can use that email address to match data feeds from the 17 affiliated Harvard hospitals and provide additional hospital specific information about each faculty member.

A person directory with email, phone and address sounds like bread and butter IT. Here's the cool part. We use the demographic information of each faculty member to connect to the National Library of Medicine's PubMed repository via web services. PubMed returns a list of all the publications of the faculty member plus all the Medical Subject Headings (MeSH terms) associated with each publication. We can then use these terms to map the interests of each person and compare these interests to every other Harvard faculty member (that's the eHarmony part). From the screen capture above, you can see a listing of my Keywords, my co-Authors and the Similar People to me. I can then click on people like me, read their Profile pages, and describe my relationship to them (that's the Facebook/LinkedIn/Plaxo part). I can also see all my advisors, advisees, and departmental colleagues and connect to them in one click.

People profiles and collaborators is just one aspect of Catalyst. It also includes Matchmaking to find skills and resources based on declared areas of expertise.

It includes an overview of all the Research Cores throughout Harvard, their scope, and contact information.

It includes Harvard-wide Events and Conferences in one easy to use cross-organizational interface.

It includes an Atlas of every associated institution's maps, phone numbers, and websites.

Finally, it includes SHRINE, an innovative, web-services based federated data mining tool that enables clinical research among all the data at all Harvard hospitals with appropriate privacy protection and IRB oversight. This infrastructure is so revolutionary that I will write a separate blog entry about it.

On July 1, we'll have pilot versions of each of these functions live.

For other CTSAs in the US (there are 60 of them) wanting more detail, we've created a matrix with a comprehensive listing of our Catalyst portal functionality.

The CTSA at Harvard is the catalyst we've needed to implement web 2.0 for HMS, part of our vision to embrace social networking for every environment.

Community Supported Agriculture

I've blogged about my vision of a Greener lifestyle including a Vegan diet, an ecofriendly home, and green data centers.

Part of my effort to do the right thing to protect my daughter's future is being a "locavore", eating food grown or harvested nearby using sustainable farming methods. Admittedly this is challenging in New England, which has 6 months of winter.

At Google's Mountain View headquarters, "Cafe 150" serves only food which is grown within 150 miles of Google. Since some of the most fertile growing areas in the country with year long growing seasons are nearby, it's possible to have sustainable, organic, local foods every day.

What do we do in New England? We can join a CSA such as Red Fire Farm.

CSA stands for Community Supported Agriculture.

The idea is that participants buy into the farm at the beginning of the growing season and receive a share of the harvest. Shares are distributed each week from June through October. With the funds contributed, the local farmer grows sustainable, organic produce without chemicals, pesticides, or herbicides. The CSA approach creates local jobs, collaboration between consumers and the farmer, and is an alternative to detrimental industrial food producers from distant regions.

One share provides all the vegetables needed for a family of 4 for a harvest season. As vegans, we buy two shares, since our diet consists entirely of vegetables, fruits and grains.

We've also planted our own extensive garden of beets, turnips, bok choy, beans, peas, squash, and lettuces in raised beds and pots using organic techniques.

Support your local CSA. Your health and the planet will thank you for it.

Enterprise Image Management

To me, the basic components of a medical record are Problems, Medications, Allergies, Notes/Reports, Lab/Micro Results, and Radiology results including images. Of all of these, image exchange between different vendor systems and among organizations is the most problematic. Standards exist to transmit the outputs of CT, MRI, Ultrasound and digital xray machines to PACS systems, but most vendors customize or extend the standards to meet their own proprietary needs. Sharing images among providers is essential for coordination of care and efficiency. The path forward to enable image sharing across vendors, modalities, and imaging technologies is not entirely clear.

Creating an archive of all image types used within an organization seems like a logical first step. I've written about the technologies to do this (Cool Technology of the Week ), which involve placing images from all departments into centralized storage devices (NAS, Data Domain appliances, tape or optical disk juke boxes) then storing metadata about the images in data repository which can be accessed by an image viewer which works with all image types.

However, there are multiple possible approaches. General Electric offers an Enterprise Archive product that is capable of managing images from multiple modalities as long as they are DICOM-based. (GE's product can manage multiple image types: jpeg, jpeg2000, DICOM, etc. in the long-term archive. However, if using their PACS Workstations, and/or Web viewer, it must be converted into a DICOM image, if it was not originally acquired in DICOM.) Teramedica's product uses a Service Oriented Architecture to retrieve DICOM and non-DICOM files from storage devices.

Joe Marion, a consultant at BIDMC working on developing a roadmap for cardiology applications and image management recently wrote a blog about these competing approaches.

It's an interesting issue. On the one hand GE is correct - DICOM is the universal standard for image management in healthcare. Utilities are available that can turn other image formats, such as JPEG, GIF and TIF, into DICOM objects. A standard DICOM viewer from GE, Merge-Efilm, or other third party should work reasonable well with DICOM formats.

On the other hand, are Flickr, Facebook and Myspace using DICOM for image management? In the world of web 2.0, you'll find technologies like SOAP/XML for managing metadata and industry standard image formats such as JPEG for storing images.

Who will win - DICOM for all healthcare images OR a flexible service oriented approach to using DICOM for some images and JPEG for others?

We're continuing to investigate the pros and cons. My prediction is that as more and more hospitals discover the importance of unified image management, multiple companies with various technology approaches will enter the marketplace. Teramedica is an early entrant with technologies that enable migration of images among different storage devices, compression based on business rules, and image deletion by replacing large DICOM objects with a small object that when viewed presents a simple graphic stating "Image deleted by policy". GE claims its approach is high performance and ensures data integrity. IBM has its GMAS product which offers a grid of storage for image management. I'm sure that Siemens, McKesson and other PACS vendors will follow soon with their products.

My advice is to assess the features needed in your institution to accomplish image viewing and archiving within the built and bought systems you have. Define the workflow needed by your users. Determine what dependency the archive creates on a single vendor i.e. if the vendor goes out of business or discontinues its product, what will your options be? Joe Marion's blog entry will help you understand the issues.

In the meantime, I'm working at the national level via the 2008 HITSP "Consultations and Transfers of Care" use case which requires we constrain the optionality of DICOM to enable exchange of images as part of a patient's lifetime medical summary. Reducing variability of DICOM will better support plug and play interoperability of images among different vendors.

In 2008, BIDMC's plan is to learn about all the approaches, convene the vendors together, and determine what is possible. You can be sure I'll share those vendor discussions with you via my blog as they happen.

EHRs for Non-Owned doctors - Roles and Responsibilities

As promised, it's June and BIDMC has begun the implementation of our Software as a Service Electronic Health Record for non-owned clinicians. As we "market" the practices on the idea of using a hospital subsidized electronic health record, we need to have all the details ready - the costs, the service levels, and a crisp definition of the roles and responsibilities of each member of our team. Since the project is comprised of 5 insourced and outsourced groups working seamlessly together (BIDMC, Massachusetts eHealth Collaborative, eClinicalWorks, Concordant, and Third Brigade), we need to have unambiguous agreement among our teams as to who will do what, who will be accountable and who will communicate the handoffs.

To ensure a perfect understanding among all stakeholders, we created a Roles and Responsibilities Matrix. There are two aspects of this work that are generally useful to other hospital systems implementing electronic health records.

1. We've defined all the component parts of an implementation, from training, to desktop support, to security

2. We've classified the roles as
Responsible - the person or team who does the work
Accountable - the person or team who reports on the work and is ultimately held responsible for its completion
Consulted - the person or team who provides an opinion when consulted as a stakeholder
Informed - the person or team who is told about the decisions made and progress achieved

Each of the 5 team members will sign of on the matrix so that there will be no misunderstandings or finger pointing.

When implementing large, complex projects, adding extra details like a roles and responsibility matrix prevent future problems. Assumptions can get teams into trouble. Well documented understandings keep everyone friendly. I hope you find it useful.

The Next Round of Standards for the Country

Tomorrow morning I present the latest round of standards harmonization to Secretary Leavitt and the American Health Information Community. Here's a preview.

Medication Management, HITSP Interoperability Specification IS07, defines specific standards to facilitate access to medication and allergy information for consumers, pharmacists, health insurance agencies, clinicians and other stakeholders.

Includes four new HITSP constructs
T40 Patient Generic Health Plan Eligibility Verification
T42 Medication Dispensing Status
TP43 Medication Orders
TP46 Medication Formulary and Benefits Information

HITSP worked with the Center for Medicare and Medicaid services (CMS) to ensure IS07 is consistent with the ePrescribing federal initiative led by CMS including adherence to standards required for ePrescribing under Part D of the Medicare Modernization Act (MMA)

IS07 uses the version of the NCPDP SCRIPT Standard Implementation Guide cited in MMA (currently Version 8.1) in most circumstances and Version 10.1 to include specialized data elements not included in Version 8.1 . To obtain and exchange local patient identifiers for communication between prescriber, dispenser, and payer organizations, IS07 defined a bridge between standards typically used in prescriber settings (HL7) with those typically used in payer and dispenser settings (NCPDP and X12N)

For exchange of a patient’s medication history, IS07 uses standards consistent with MMA to exchange medication history detail (NCPDP SCRIPT) and standards to include medication history in a clinical summary that also includes allergies, problem lists, etc. (HITSP C32, the Continuity of Care Document)

These standards are mature and already are widely used. Given the maturity of e-Prescribing standards, I signed a letter to Congress supporting the Medicare Electronic Medication and Safety Protection Act of 2007, noting that standards are no longer a barrier to medication management and e-prescribing.

I'll also present "Document reliable interchange", HITSP Technical Note T31, which provides a standards-based mechanism for exchanging medical documents securely over a network. This includes interchange among EHRs, PHRs, Quality Measurement Organizations, Public Health Authorities and other healthcare IT systems. This simplified document exchange and sharing mechanism does not require the use of XDS, the document sharing infrastructure described by the Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework. Instead it uses IHE Cross-Enterprise Document Reliable Interchange (XDR) Integration Profile, which is very easy to implement.

In the current Beth Israel Deaconess pilot project with the Social Security administration to exchange medical records for disability benefits adjudication, we will be using this set of standards. T31 provides the specifics to use SOAP and HTTPS, mature standards that are used for many web 2.0 data exchanges.

If I were to forecast where all this standards effort is leading, over the next few years, I'd summarize our progress as

2007
*Standardize point to point messaging by harmonizing the work standards development organizations have done for the past 10 years
*Standardize security

2008
*Begin transition to persistent document formats with CCD/CDA Document summary, transmitting legally non-repudiable document summaries instead of just transient messages.

2009 Continue to add data elements to the CCD/CD Document Summary
*Further consolidate vocabularies used across SDOs
*SDOs begin developing standards collaboratively so that they arrive at HITSP with some pre-harmonization

2010
*Vendor products produced with document exchange and security constructs built in
*Regional exchanges built with these standards


It's a great time for standards in the US and I believe the 500 organizations in HITSP are making a real difference on the path toward interoperability.