Tuesday, April 27, 2010
Physician Plans for Adoption of Health IT Systems
Healthcare Technology News sat down with Greg Parston, the lead researcher and director for Accenture’s Institute for Health and Public Service Value.
HTN: This study is focused on the 10 and under physician market in US?
Greg Parston: That’s correct.
HTN: The physicians have pretty aggressive plans.
Greg Parston: Because of what’s happening with incentives provided by ARRA and sometimes being provided by hospitals we are at a tipping point. There have been many physicians who appear to have been looking into what EMR can do for them. They’ve been reluctant for many reasons that we identified in the study. But because of these incentives and in part because they can anticipate minor Medicare reductions for non-use, they are becoming more interested. The indications of aggressiveness, if you can call it that, are pretty astounding.
80% of physicians under the age of 55 we talked so say they are going to adopt an EMR system within the next two years and that’s a pretty big shift. Right now we’re talking about a physician population of about 15% using on EMR and now we were talking about much bigger numbers within 24 – 36 months.
HTN: There’s always been a prediction that the EMR adoption was right around the corner.
Greg Parston: Physicians have been looking. It’s not as if they’re coming to this totally uninformed. Many practices have been taking a look at different kinds of systems. They’ve been considering the benefits. They’ve been talking to people who have a system today. I don’t think they’ve been doing enough of that. But they’ve been doing enough of it to indicate that they been thinking about it. So if we’re talking about 58% now, a good portion of that would have been thinking about adopting it in the coming years. What ARRA has done is to provide the tipping point to make a much larger percentage of small-group practices decide that they're going implement a system. But also because of the deadlines it’s brought their plans closer. You’re right to say that there was a time we thought this was going to happen and there was going to be a big surge. What ARRA has done is to provide the added push and the timetable for that.
What’s most interesting is the difference in attitude amongst those physicians under 55 and those over 55. These systems are not inexpensive. For very small packages it’s a sizable amount of money. For the older guys they’re there taking a look at when are these reductions going to come in. How much is it going to cost me? When am I going to retire? Those sorts of questions are making them in some cases perhaps a bit more skeptical of it. More wary of it. More reluctant. When you take a look at the younger guys, 2015 (when the penalties kick in) is still within their working lives. They’re taking a look at how they can avoid any penalties now and put in place a system which potentially has great benefits for them.
HTN: Your study cited a key driver for EMR adoption being federal legislation - 61% cited penalties for non-adoption and 51% cited federal incentives.
Greg Parston: You can’t just look at their reaction to ARRA. You also have to take a look at their reaction to the potential of local hospital subsidy. Many local hospitals are offering support of one type or another and some of that support is actually financial. There’s also aftercare – we’ve heard of doctors who have had a systems crash and have waited up to three weeks for the geek squad to fix it. Hospitals are offering 24x7 services. Hospitals are offering training. Hospitals are offering assistance in transition from written records to electronic records. All of those things along with ARRA are providing a basket of benefits for clinicians.
And while the study does cite the penalty as the single most importat thing, when you combine the benefits of both the government and their potential networked hospitals, these incentives seem to be the overwhelming influence.
If doctors move to full functionality EMR systems, however meaningful use is finally defined, and if they negotiate well with their local hospitals this could be a rather inexpensive investment for them. As they’re thinking about this, they’re thinking about how they could network in to hospitals. This brings them advantage, not just in terms of billing but in terms of patient flow through their referrals. In another study we found that 75% of the American public want their doctors to have electronic medical records and that must put pressure on practices as well. They’re sitting there saying: “This looks pretty good - I can get up to X thousands from the government to put in the system and my local hospital is willing to put in training and support for me - Now is the time.”
HTN: The study found a strongly held belief in the value of an EMR system to the practice. The summary in the study was about changing the way the practice works for the better. I hear various arguments: Are the majority of of practices using it just to comply with billing and payment requirements for reporting outcomes? Or are they really into this for better patient care? What is your insight on how this changes the way the practice works for the better?
Greg Parston: Patient care came up but it wasn’t the top. What was top was trying to develop more streamlined administrative systems within the practice. And that’s fine. These guys run businesses and they’ve got to make sure that those businesses are giving them the kind of support and administrative ease that allows them to focus on their patients.
When we ask doctors who currently have systems whether the systems benefitted them, 90% said they did. There wasn't any one thing that was identified as the overwhelming benefit. Doctors use these systems in various ways for various advantages in various places. Places that have used systems for a very long time like Kaiser Permanente have learned how these systems can not only streamline administrative practices but can also streamline and improve the quality of the patient care process. There are organizations that really know how to use the EMR. I’m not sure that doctors who are in small practices are cognizant of all the potential benefits and changes possible with an EMR system in place.
HTN: The study noted the exaggerated perception of the difficulties in using EMR systems. How did that manifest itself?
Greg Parston: It manifested itself in the fear and hesitancy about the systems. There is another important observation here that came out of the research. Many of these physicians self-report themselves as being less conversant and less comfortable with computer and Internet technologies than their predecessors. So the first wave who are already using it – the 15% who are already there - they identify themselves as more IT literate. Some develop these systems because they want to be on the edges of modernity. You and I have friends that have every piece of technology around the house because they have to have it. There are doctors like that too.
The next generation if we can call it that – the people we were talking in that 58% (or under 55, that 80%), they’re more fearful. They don't feel as comfortable with these technologies. They certainly don't feel able to service it themselves. So they raise bigger questions about how difficult is it going to be implement it or how difficult it’s going to be to get service. Am I going to find that it’s going to crash and am I going to run into real problems in my practice? Those questions don't come from looking at the systems. Those questions come out of their own personal lack of total comfort with new technologies. That’s something that’s going to have to be overcome through learning more and through use of these systems. And here I think that vendors and hospitals that are trying to network doctors in can be of enormous help in providing much more education and support and understanding to make them much more comfortable more quickly.
HTN: What was the timing of your survey? Was this pre- December 30, before the meaningful use rules were issued?
Greg Parston: Yes it was. It was also right during the height of the health reform legislation. We had been timing this study to occur in the Autumn and we took a judgment about whether or not we should do it during the midst of that debate. We decided we should because people would be even more cognizant and sensitive to the issues. Healthcare reform legislation is going to change American healthcare.
HTN: What do you think would be the impact of the meaningful use rules on physicians planning to adopt an EMR?
Greg Parston: There’s 600 pages there and I only know one person who’s read all 600 hundred. And they’re still being modified as we speak. Meaningful use is essentially about trying to get people to use the system to full functionality, cognizant that people are concerned about privacy issues and lots of other things. Meaningful use will drive people to take a look at what they get from that next step of functionality. By linking the incentive payment to increased meaningful use physicians will begin to explore more.
They’re not going to jump all the way into whatever the top level of meaningful use is simply to get the money. But knowing that the money is there, they’ll begin to explore further the edges of their systems. And they’ll begin to think about how they can use them in a new ways.
I’ve already mentioned Kaiser Permanente. There’s a quote in recent article about Kaiser Permanente – about how the system can actually change things - about how doctors will use these technologies to adapt their practices. The quote goes something like this: that if you give a lumberjack, who’s been using an ax his whole life, a chainsaw and he starts hacking at the tree it’s not going to help him. It's only when you begin taking a look at how this chainsaw works and what a difference it can make that it can make a difference in his life. I think that’s the same with an EMR.
This is a new technology that’s going to allow people to do lots of different things. Meaningful use is a carrot as well as an instruction about how you can learn how to use the chainsaw in the way it was designed to be used.
HTN: You mentioned the striking impact the health reform legislation will have.
Greg Parston: It’s going to force people to take a look at what we mean by connected health. I don't mean that in a technology sense. I mean it in the sense of really connecting agencies together to try to deliver value for the public in health terms, not just in health service terms. And that’s pretty exciting to me. This legislation will unleash a whole new part of the market on the demand side. And there are people on the supply side that are very good at innovation and thinking about how they can serve the needs of people who have not been served before. And a lot of that isn’t episodic acute care. I think we could see a very different health system in two decades from what we've got now. What we’ve got now is one that largely focuses on episodic transactional care. I think we can get something which is much more about helping me deal with my health through the continuum of my life.
________
Greg Parston is the director of the Accenture Institute for Health & Public Service Value. Prior to joining Accenture, Dr. Parston was the chairman of the Office for Public Management, a nonprofit organizational development company that he co-founded in 1988 and led as chief executive until 2003. Dr. Parston has consulted widely with top managers, focusing on governance, strategy and change and has worked as a manager in the public, private and not-for-profit sectors. Until taking up his current post, he also was a director of the Priory Group, responsible for public service partnerships.
Wednesday, August 19, 2009
HITSP Approves New Interoperability Specifications in Line with ARRA
- IS107 - Electronic Health Record (EHR)-Centric Interoperability Specification
- TN904 – Exchange Architecture & Harmonization Framework Technical Note
- TN903 – Data Architecture Technical Note
- SC108- SC116 – Service Collaborations
In response to the HIT requirements of ARRA, HITSP leveraged its work products – 13 Interoperability Specifications (IS) and 60 related constructs – to consolidate all information exchanges that involve an Electronic Health Record (EHR) system.
HITSP formed temporary “tiger” teams to map EHR-related information exchanges to ARRA requirements. These teams identified “Capabilities” – specific, implementable business services that use existing HITSP constructs to define and specify interoperable information exchanges. For example, the Communicate Hospital Prescriptions Capability addresses the interoperability requirements needed to support electronic prescribing for inpatient prescription orders.
In total, twenty-six Capabilities were defined that support the workflow, information content, infrastructure, and security and privacy requirements laid out in the ARRA legislation. All of the Capabilities are defined in IS107 –EHR-Centric Interoperability Specification.
HITSP Capabilities also address the “meaningful use” requirement of ARRA. ONC’s Health IT Policy Committee recommended a definition of meaningful use that names seven different electronic exchanges to be required by 2011: ePrescribing, lab results, clinical data summaries (problems, medications, allergies, laboratory reports) from provider to provider, Biosurveillance, immunization registries, public health, and quality measurement.
“HITSP Capabilities provide specific transactions supporting all seven of these required exchanges and others that will be needed in 2011, 2013, and beyond,” said HITSP Chair John Halamka.
Definitions of the capabilities and service collaborations include:
HITSP/CAP117 Communicate Ambulatory and Long Term Care Prescription
This capability addresses interoperability requirements that support electronic prescribing in the ambulatory and long term care environment. The capability supports:
1. The transmittal of new or modified prescriptions
2. Transmittal of prescription refills and renewals
3. Communication of dispensing status
4. Access to formulary and benefit information
HITSP/CAP118 Communicate Hospital Prescription
This capability addresses interoperability requirements that support electronic prescribing for inpatient orders that can occur within an organization or between organizations. The capability supports the transmittal of a new or modified prescription from a Hospital to an internal or external pharmacy. It also includes the optionality to access formulary and benefit information.
HITSP/CAP119 Communicate Structured Document
This capability addresses interoperability requirements that support the communication of structured health data related to a patient in a context set by the source of the document who is attesting to its content. Several document content subsets, structured according to the HL7 CDA standard, are supported by this capability. The following are examples of the type of structured data that may be used:
1. Continuity of Care Document (CCD)
2. Emergency Department Encounter Summary
3. Discharge Summary (In-patient encounter and/or episodes of care)
4. Referral Summary Ambulatory (encounter and/or episodes of care)
5. Consultation Notes
6. History and Physical
7. Personal Health Device Monitoring Document
8. Healthcare Associated Infection (HAI) Report Document
Document creators shall support a number of the HITSP specified coded terminologies as defined by specific content subsets specified in this capability.
HITSP/CAP120 Communicate Unstructured Document
This capability addresses interoperability requirements that support the communication of a set of unstructured health data related to a patient in a context set by the source of the document who is attesting to its content.
Two types of specific unstructured content are supported, both with a structured CDA header:
1. PDF-A supporting long-term archival
2. UTF-8 text
HITSP/CAP121 Communicate Clinical Referral Request
This capability addresses interoperability requirements that support provider-to-provider (clinical) referral request interaction. It allows the bundling of the referral request document with other relevant clinical documents of interest by referencing such documents as shared by other capabilities such as:
CAP119 Communicate Structured Document; CAP120 Communicate Unstructured Document; or CAP133 Communicate Immunization Summary.
HITSP/CAP122 Retrieve Medical Knowledge
This capability addresses the requirements to retrieve medical knowledge that is not patient-specific based on context parameters. The actual content delivered is not constrained by this capability; this capability focuses on providing the mechanism to ask for (query) and receive the medical knowledge.
HITSP/CAP123 Retrieve Existing Data
This capability supports queries for clinical data (e.g., common observations, vital signs, problems, medications, allergies, immunizations, diagnostic results, professional services, procedures and visit history).
HITSP/CAP124 Establish Secure Web Access
This capability is focused on providing a secured method to access information available from document repositories (e.g., Laboratory Report) in order to view them locally on a system. The chosen method for viewing the document content is through a web browser.
HITSP/CAP125 Retrieve Genomic Decision Support
This capability addresses interoperability requirements that support the communication of genetic and family history information and an assessment of genetic risk of disease for a patient.
HITSP/CAP126 Communicate Lab Results Message
This capability addresses interoperability requirements that support the sending of a set of laboratory test results. Ordering Providers of Care receive results as a laboratory results message. The communication of the order is out of scope for this capability.
The content of these test results may be either or both: General Laboratory Test Results; Microbiology Test Results
This capability may use content anonymization.
HITSP/CAP127 Communicate Lab Results Document
This capability addresses interoperability requirements that support the communication of a set of structured laboratory results related to a patient in a context set by the source of the document who is attesting to its content. Non-ordering Providers of Care access historical laboratory results as documents and "copy-to" Providers of Care may receive document availability notifications to retrieve such lab report documents.
Lab Report content creators shall support HITSP specified coded terminologies as defined by specific content subsets specified in this Capability for: General Laboratory Test Results; Microbiology Test Results
This capability may use content anonymization.
HITSP/CAP128 Communicate Imaging Information
This capability addresses interoperability requirements that support the communication of a set of imaging results (i.e., reports, image series from imaging studies) related to a patient in a context set. This is done by an Imaging System acting as the information source attesting to its content.
This capability may use content anonymization.
HITSP/CAP129 Communicate Quality Measure Data
This capability addresses interoperability to support hospital and clinician collection and communication of patient encounter data to support the analysis needed to identify a clinician or hospital’s results relative to an EHR-compatible, standards-based quality measure.
Quality measures may include:
1. Patient-level clinical detail from which to compute quality measures. Patient level clinical data is compiled from both the local systems and from longitudinal data available through other sources such as a Health Information Exchange (HIE).
2. Patient-level quality data based upon clinical detail. The “patient-level quality data reports” are exported from EHRs or quality-monitoring applications at the point of care
This capability may use content anonymization. Pseudonymization, if needed, is supported by the Capability 138 Retrieve Pseudonym.
This capability may use Value Set Sharing.
HITSP/CAP130 Communicate Quality Measure Specification
This capability addresses interoperability requirements for an EHR-compatible, standards-based quality measure. In the measure specification, needed patient encounter data elements are identified so they can be extracted from local systems and from longitudinal data available through other sources such as a Health Information Exchange (HIE). The measure specification also includes various sets of exclusion/inclusion criteria to identify which patients to include in calculation of the measure. This capability may use Value Set Sharing.
HITSP/CAP131 Update Immunization Registry
This capability addresses interoperability requirements that enable electronic communication of immunization data among clinicians, with patients, and with immunization registries as unsolicited structured patient immunization data.
This capability may use content anonymization.
HITSP/CAP132 Retrieve Immunization Registry Information
This capability addresses interoperability requirements that support the query and retrieval of structured immunization data related to a patient’s vaccination.
The capability may use one of the following:
1. HL7V2 query with implicit Patient Identity resolution
2. HL7V2 query with explicitly Patient Identity resolution prior to query
3. HL7V3 Query for Existing Data
The query for immunization documents from Capability 133 - Communicate Immunization Summary may also be used.
HITSP/CAP133 Communicate Immunization Summary
This capability addresses interoperability requirements to support the communication of structured health data related to a patient’s vaccination history. This immunization document contains a history of administered vaccines with details such as lot number, who administered it, as well as other information related to the patient's care such as medical history, medications, allergies, vital signs.
HITSP/CAP135 Retrieve and Populate Form
This capability addresses interoperability requirements to support the upload of specific captured data (e.g. public health surveillance reportable conditions, healthcare associated infection reporting) to Public Health Monitoring Systems and Quality Organizations Systems. The forms presented may be pre-populated by information provided by the clinical or laboratory information systems to avoid manual re-entry. A number of supplemental information variables may be captured from within the user’s clinical information system to improve the workflow and timeliness of required reporting. One or more types of form content may be supported:
1. Pre-population for Public Health Case Reports from Structured Documents using CDA
2. Pre-population for Quality Data from Structured Documents using CDA
3. No pre-population content
Systems may optionally support the means to retrieve request for clarifications.
HITSP/CAP136 Communicate Emergency Alert
This capability addresses interoperability requirements to support multicast of non-patient specific notification messages about emergencies events, alerts concerning incidence of communicable diseases, alerts concerning population needs for vaccines and other generic alerts sent to an identified channel. The intended recipients are populations such as “all emergency departments in XXX county”, “within a geographic area”, etc. Note that this capability is not used to communicate patient-specific or identifiable data.
HITSP/CAP137 Communicate Encounter Information Message
This capability addresses interoperability requirements to send specific clinical encounter data among multiple systems.
The content may be either or both:
1. Encounter Data Message
2. Radiology Results Message
It may be used in conjunction with other capabilities such as those related to the communication of laboratory data. This capability includes optional anonymization of content.
HITSP/CAP138 Retrieve Pseudonym
This capability addresses interoperability requirements to support a particular type of anonymization that both removes the association with a data subject, and adds an association between a particular set of characteristics relating to the data subject and one or more pseudonyms. This enables a process of supplying an alternative identifier, which permits a patient to be referred to by a key that suppresses his/her actual identification information. The purpose of this capability is to offer a pseudonymization framework for situations that require the use of specific data without disclosing the specific identity of patients or providers. Pseudo-identifiers are intended to allow accessibility to clinical information, while safeguarding any information that may compromise the privacy of the individual patient or provider. However, unlike anonymization, the alternative identifier key can be used to re-identify the individuals whose data was used.
HITSP/CAP139 Communicate Resource Utilization
This capability specifies the message and content necessary to report utilization and status of health provider resources to systems supporting emergency management officials at local, state or national levels who have a need to know the availability of hospital and other healthcare resources. The resource utilization information may be provided routinely or in response to a request.
HITSP/CAP140 Communicate Benefits and Eligibility
This capability addresses interoperability requirements that support electronic inquiry and response from a patient’s eligibility for health insurance benefits. The information exchanged includes the following:
1. A patient’s identification (i.e., name, date of birth, and the health plan’s member identification number)
2. Communication of a member’s status of coverage and benefit information and financial liability
3. Access to information about types of services, benefits and coverage for various medical care and medications.
It provides clinicians with information about each member’s health insurance coverage and benefits.
HITSP/CAP14 Communicate Referral Authorization
This capability addresses interoperability requirements that support electronic inquiry and response to authorizing a patient (health plan member) to be referred for service by another provider or to receive a type of service or medication under the patient’s health insurance benefits.
The capability supports the transmittal of a patient’s name and insurance identification number with the request for the type of service. It also includes the following optional requirements:
1. Identification of the type of service or medication requested for benefit coverage (does not guarantee payment by insurance provider)
2. Communication of a referral notification number or authorization number from the Payer System to the Provider SystemIt provides clinicians and pharmacists with information about each patient’s medical insurance coverage and benefits. It may include information on referral or authorization permission.
HITSP/CAP142 Retrieve Communications Recipient
This capability addresses interoperability requirements that support access to a directory to identify one or more communication recipients in order to deliver alerts and bi-directional communications (e.g., public health agencies notifying a specific group of service providers about an event). The method and criteria by which individuals are added to a directory is a policy decision, which is out of scope for this construct.
HITSP/CAP143 Manage Consumer Preference and Consents
This capability addresses management of consumer preferences and consents as an acknowledgement of a privacy policy. This capability is used to capture a patient or consumer agreement to one or more privacy policies; where examples of a privacy policy may represent a consent, dissent, authorization for data use, authorization for organizational access, or authorization for a specific clinical trial. This capability also supports the recording of changes to prior privacy policies such as when a patient changes their level of participation or requests that data no-longer be made available because they have left the region.
A Service Collaboration is the composition of HITSP Transaction and or Transaction Package constructs into a reusable workflow, primarily at the infrastructure level. Service Collaborations do not contain content, i.e., Components. Service Collaborations are organized into an external view, i.e., outward facing interfaces, and an internal view that includes inward facing interfaces and HITSP Transactions and Transaction Packages. Security and privacy constructs are incorporated into the infrastructure Service Collaborations.
SC10 Access Control - The HITSP Access Control Service Collaboration provides the mechanism for security authorizations which control the enforcement of security policies including: role-based access control, entity based access control, context based access control, and the execution of consent directives.
SC109 Security Audit - The HITSP Security Audit Service Collaboration describes the mechanism to record security relevant events in support of policy, regulation, or risk analysis. It also provides the mechanism to determine the record format to support analytical reports that are needed.
SC110 Patient Identification Management - The HITSP Patient Identification Management Service Collaboration provides the ability to lookup and/or cross-reference patient identities.
SC111 Knowledge and Vocabulary - The HITSP Knowledge and Vocabulary Service Collaboration provides the ability to retrieve medical knowledge and terminology.
SC112 Healthcare Document Management - The HITSP Healthcare Document Management Service Collaboration provides the ability to share healthcare documents using a set of topologies, such as Media, e-Mail, Point-to-Point, Shared within a Health Information Exchange, and Shared within a larger community (made up of potentially diverse Health Information Exchanges).
SC113 Query for Existing Data - TheHITSP Query for Existing Data Service collaboration provides the capability to query and retrieve data from another clinical system, and the capability to respond to same queries. It applies the necessary Security and Privacy constructs and supports all the queries found in HITSP/TP21.
SC114 Administrative Transport to Health Plan - The HITSP Administrative Transport to Health Plan Service Collaboration provides the transport mechanism for conducting administrative transactions with health plans.
SC115 HL7 Messaging - The HITSP HL7 Messaging Service Collaboration provides the capability to send and receive HL7 messages. This Service Collaboration applies the necessary Security and Privacy constructs.
SC116 Emergency Message Distribution - The HITSP Emergency Message Distribution Service Collaboration performs a multicast notification to specifically identified populations, such as emergency departments.
Monday, June 22, 2009
CCHIT To Provide 3 Certification Options

- "A rigorous certification for comprehensive EHR systems that significantly exceed minimum Federal standards requirements. This certification (EHR-C) would be targeted to the needs of providers who want maximal assurance of EHR capabilities and compliance
- A new, modular certification program for electronic prescribing, personal health records, registries, and other technologies. Focusing on basic compliance with Federal standards and security, the EHR-M program would be offered at lower cost, and could accommodate a wide variety of specialties, settings, and technologies. It would appeal to providers who prefer to combine technologies from multiple certified sources.
- A simplified, low cost site-level certification. This program would enable providers who self-develop or assemble EHRs from noncertified sources to also qualify for the ARRA incentives."
These certification options are targeted to be available for 2011-2012 certifications which kick off in January 2010.
CCHIT's announcement addresses the concern that certification was previously only available to vendors able to deliver monolithic solutions covering all EHR requirements.
Tuesday, March 17, 2009
Not If, But When
The lead highlights the significant financial benefit for physicians who "must act quickly to achieve the biggest benefit and avoid penalties." And contrary to many reports, AMNews gets it right in describing the payment of $35 billion in Medicare and Medicaid physician incentives. The net $20 billion normally associated with the health care technology stimulus includes the offsetting penalties that begin in 2016.
For the full explanation of bonuses and penalties (pdf) click on the graphic below:
