a dissection (no pun intended) of the EMR market
On behalf of a peer, Chris Thorman, I offer his breakdown of the EMR market:
- The size of the outpatient EMR market;
- What EMR vendors have the most physicians using their system; and,
- What EMR vendors have the most practices using their system.s
Trend away from private practice?
An article in the New York Times describes the movement of physicians from private practice to becoming employees of medical clinics. Of particular interest to me was this:
But an even bigger push may be coming from electronic health records. The computerized systems are expensive and time-consuming for doctors, and their substantial benefits to patient safety, quality of care and system efficiency accrue almost entirely to large organizations, not small ones. The economic stimulus plan Congress passed early last year included $20 billion to spur the introduction of electronic health records.
I question the above statement for the following reasons:
- Cost: Web based (SaaS) EMRs such as those offered by PracticeFusion (actually free), SOAPware, and others are less expensive since the Physicians do not have to maintain expensive in-house hardware and software.
- Time-consuming for doctors: I don’t see why an EMR used by private practice is any more time consuming than an EMR used in a clinic. All a Physician has to do is learn to type with 10 fingers and he/she will discover e-prescribing, electronic lab orders, faster patient search etc are features that far outweigh their paper alternatives.
- Patient safety and quality of care: These benefits accrue equally to users of EMRs be they in private practice or clinics.
EMRs and Clinical trials – some questions….and answers
Chris Thorman, from a web site that reviews of electronic health record programs, posted a good article proposing that data from Electronic Medical Records (EMRs) be used for clinical trials, with the following benefits for Physicians considering the purchase of an EMR:
- Participating in these trials is easier through an EHR than through traditional paper means;
- Using EHR data solves many of the major problems that clinical trials face; and,
- Purchasing an EHR creates a big ROI for physicians who decide to participate in clinical trials.
In theory, this sounds great and I found one example: the renowned Mayo clinic’s effort with Centerphase.
I ask the following questions, offer my answers, and welcome comments.
- What part of the pre-consent record can a clinical trial investigator access? Only data that is marked ‘non-confidential’ and does not identify the patient.
- As a follow on, if the trial investigator is allowed to see pre-consent eligibility or screening attributes only, how can access to the rest of the patient record be suppressed? Implement strict fine grained access controls at the attribute level of a patient record.
- Can the investigator access pre-consent data that is marked as confidential? He/she cannot!
- Can the patient waive confidentiality or regulatory access restrictions on sensitive pre-consent data? Only with full understanding of the implications
- If clinical trial specific data is co-mingled with standard care data, is that data available for insurance/reimbursement purposes? No
- As a follow on, what constitutes the “legal medical record” when clinical trial and standard care data are commingled? Only standard care data, acquired by a diagnosis
- When a study subject either completes a study or withdraws study consent, does their research-only data remain part of the permanent EMR database? No, it should be erased
- Assuming access to trial-specific data is allowed, can a physician who is not a clinical trial investigator, change trial data that they feel are incorrect? No
- Should research data be separated from standard clinical care data? Yes
- Is there a difference in access rights between standard care data that will be included in the research versus standard care data that will not be included in the research? No, clinical trial investigators should only have access to data that is included in the research.
MUMPS anyone?
As a kid I got mumps and stayed home from school with swollen glands; today there is the MMR vaccination for children fortunate to live in developed countries.
I am not writing about the disease though, rather the programming language used to create electronic medical record software, for example: VISTA and EPIC. This is another assignment from my class, Healthcare Informatics – the University of California, Davis.
If you were writing a new Electronic Medical Record (EMR) software solution today, would you use MUMPS, which is admittedly widely deployed?
Those in favor might argue:
- MUMPS is the language used by existing EMR deployments from large established EMR vendors,
- The MUMPS database does not waste disk space as it uses sparse arrays and B-trees queries are faster than indexed relational databases.
- MUMPS based EMR systems installed today are stable and reliable.
I posit no, because:
- Where would you find MUMPS programmers today? Are new college graduates proficient in MUMPS or JAVA/C++ ?
- How would you interface with other EMRs today? Interoperability is the one of the biggest challenges between healthcare systems today and creating a new EMR system based on older non-standards approaches will not result in an interoperable system.
- Rather than run a MUMPS based system on large monolithic hardware, a new EMR system could be written on distributed highly available hardware.
Of course there is also the option of not writing your own EMR software, but rather using a Cloud computing EMR solution from vendors such as AdvancedMD or (my local favourite) Practice Fusion.
How to select and deploy an Electronic Medical Record system
This blog entry is a brief summary of readings I have covered as part of my training in healthcare Informatics from the University of California, Davis and is sourced from this paper and this book
The medical practice has to be ready to adopt an EMR and most importantly to recognize that the medical practice is adopting a vision, not just a technology. A vision means the practice will offer better patient care, a more efficient office and improved financials. The most important role in the implementation of an EMR is a ‘champion’. The role of this champion is to gain buy-in and trust from perhaps reluctant staff in the medical institution, since workflows and business processes will likely change. Users of the new system must have high psychological ownership of the new technology.
Steps in the implementation of an EMR
Information gathering
- Collect information: Patient data, radiology and lab reports
- Assess workflows: Appointment scheduling, events during and after a patient visit, unscheduled visits and questions etc
- Financial impact: Beyond the initial cost of the software are costs for training, maintenance and upgrades.
Selection Phase
Subsequent to information gathering, the medical practice selects an EMR. A few choices: proprietary vendors such as EPIC, Cerner and Eclipsys or OpenSource alternatives . Both require creating evaluation criteria and extensive RFI/RFP processes by a project steering committee. Furthermore members of the medical practice should visit other practices and view their EMR implementations.
Keys to success
- People are key to the successful implementation of an EMR. Everyone, clinicians and yes patients, must be aware of the new system to gain buy-in.
- Workflow will be redesigned
- A good project plan: just like the rollout of any enterprise software system, a good project plan is required that that clarifies responsibilities, sets objectives, generates tasks, and provides tight control and feedback with ongoing problem solving.
Alternative solution to installing an EMR
Of course a simpler alternative would be to select a hosted SoftwareAsAService (SaaS) offering that requires no in-house software, servers, or expensitve technical support staff. A SaaS solution that I like and have interacted with over the blogosphere is Practice Fusion. Contrarians might argue that a hosted service is a one-size-fits all solution that does not fit the current practices of a medical practice. I would counter that an in-house system will be expensive to modify to suit a medical practice’s needs.
Hosted or in-house, the medical institution must recognize that their workflows and practices will have to change if they wish to gain the undeniable benefits on an Electronic Medical Record.
Image below courtesy of HIMS Analytics
Will you entrust the US government or a private entity with your electronic medical records?
The ARRA stimulus bill provides incentives for medical providers to use Electronic Medical Records for storing patient healthcare information. (To read more about Meaningful Use and certified Electronic Medical records, beyond the scope of this posting, please refer to CCHIT). The overarching goal is to allow medical records to be exchanged between health-care providers. A simple example: An employee changes jobs and receives new health insurance, which requires him to use a different healthcare provider. How does he transfer his medical records to that new health-care provider. Or a soldier is treated in a military hospital, then transferred to the VA and finally to a public/private hospital. How does his/her electronic medical record transfer between the three distinct institutions.
In transferring electronic patient data between institutions:
- How does American law protect the privacy and security of patient health-care data?
- Why are Americans hesitant to share medical information electronically?
On Monday January 25th, 2010 a study by the Ponemon institute revealed that Americans distrust the Federal Government or private enterprise to electronically store their health-care data.
Of the 868 Americans surveyed about their views on digitizing and storing health records, only 27% said they would trust a federal agency to store or access the data–the same percentage as those who would trust a technology firm like Google Microsoft or General Electric
Let’s examine how US Federal law protects electronic medical records
- HIPAA – Health Insurance Portability and Accountability Act – is rather dated (1996) in terms of protecting electronic medical records. HIPAA does not take into account the electronic exchange of electronic health data.
Health Insurers and Providers who are covered entities must comply with your right to:
- Ask to see and get a copy of your health records
- Have corrections added to your health information
- Receive a notice that tells you how your health information may be used and shared
- Decide if you want to give your permission before your health information can be used or shared for certain purposes, such as for marketing
- Get a report on when and why your health information was shared for certain purposes
Nothing implied about electronic medical records, nor exchange of electronic data and most importantly authenticating the individual who is requesting access to the records. In an electronic medical record system, how can I be certain that Joe Smith is who he claims to be when he logs into the system. Is user-name password sufficient security?
- In light of the ARRA stimulus bill, the US Department of Health and Human Services (HHS) revised the privacy rule in December 2008. (11 page PDF here). In summary:
- Access: Individuals must be provided timely access to their medical data
- Disputation/Correction: Individuals must be able to dispute and correct information in their health record, from a simple typo, corruption of digital information in transit between entities and even medical identity theft.
- Openness/Transparency: Individuals must have access to their record and know what is in there and how it is disclosed.
- Individual choice: Individuals must be able to choose how data is shared. For example which doctor is allowed to view their record delegating access to another person in case the individual/patient is incapacitated and cannot access their record.
- Collection/Use: Individuals have the right to know how their medical data is distributed/used; that data is only used for their care and not distributed beyond the patient’s consent.
- Data quality/integrity: Data is secure and not compromised
- Accountability/Auditing: An audit trail and legal accountability exists to know who was authenticated and authorized to access an individual’s data.
The word “trust” appears 13 times in the 11 page document, the phrase “trust in electronic exchange of information” appears six times. Clearly the HHS is attempting to gain the public trust in an electronic exchange of health data.
- The Federal Trade Commission proposed a breach notification rule (50 page PDF) “requiring vendors of personal health records and related entities to notify individuals when the security of their individually identifiable health information is breached.”
So, given the above laws, why does the Ponemon study find Americans so distrustful to store their electronic health data. The study revealed: Users rated health records as far more sensitive than other information they typically share with Web companies. On a scale from one to seven, medical data received an average rating of 6.64, while credit card information received only a 4.27 and online search records just a 1.86.
I posit that:
- Internet searches can be reasonably anonymous. I can search for information from a public computer such as the library or a firewall can transform my computer’s identity (IP address).
- If my credit card information is compromised I am protected by the credit card company; so much so that credit card companies have sophisticated software that track errant spending patterns and forewarn me. Am I in an obscure overseas country attempting to purchase a $3000 airline ticket?
- Americans, historically, have a distrust in their government. The Bill of Rights dating back to 1791 protects the individual (for example unreasonable searches). So why should the government be trusted with personal health information?
The problem is health information potentially reveals personal and important details about an individual: their weight, medications, illnesses, addictions, allergies, perhaps even sexual preferences. (Interestingly under the US law, patients do not have access to their psychotherapy notes. See HIPAA rule “You do not have the right to access a provider’s psychotherapy notes.” )
The real problem I believe is what options does a an individual have if their electronic medical record has been compromised? Witness two recent incidents in California where electronic patient information was stolen: UCSF – (600 patients) and Kaiser (15000 patients).
Is the FTC breach rule sufficient?
I think the rule is sufficient, but the ubiquity, and ease of electronic data duplication, makes it difficult to gain the trust of users. If my medical records are stolen, what comfort is the rule? The answer individuals require from electronic medical record vendors is “we will encrypt your data, at rest and in transit.” At rest means data in a database is encrypted; in transit means, that the data as it is transmitted across computer networks. Today, encryption in transit is easily achieved with SSL. Encryption at rest is rare because it is practically difficult to implement. If I encrypt “Joe Smith” as “aS@Pn!”, then how do I search for his record, as I cannot search for “Smith”? How does another, say reporting application, access and present the encrypted data? How do I index a database (group all the “Smith”s together) if the data is encrypted? How can a receiving party in another institution (sharing electronic medical records) decrypt the data? As the UCSF and Kaiser incidents note, unencrypted data was stored on detachable disks and subsequently stolen.
Electronic medical record vendors and the US government have a long way to go to gain public trust.
(This posting is an assignment from my UC Davis Informatics class on telemedicine)
A simple data model for an Electronic Medical Record
I present a simple data model for an EMR created using ARGO UML
Key components of this model:
- Patient – the person treated by the physician
- Physician – doctor
- Medication – drug prescribed for a diagnosis
- Encounter – a patient visit
- Diagnostics – what the physician deduces is wrong with the patient.
Relationships:
- 1:1 (one to one) – where one component can only be related to one instance of another component.
- 1:m (one to many) – where one component is related to several instances of another component
- m:m (many to many) – where several components are related to several instances of another component
Below is the model with comments alongside each object and each relationship
Security for Personal Information stored in Electronic Medical Records
Security and privacy of electronic personal health information entails the same concepts as security for other electronic data, such as personal financial data.
I believe the top three requirements for security of electronic data are:
- Confidentiality – keeping data hidden. Data is encrypted both at rest (in the database) and during transfer (over TLS/SSL)
- Integrity – Ensure data is trustworthy and has not been modified. This can be accomplished using digital signatures.
- Access – Access and audit controls. Implement access controls to control who can access the data. Often this is implemented as the least privilege principle: only grant a user the role or privilege to access the minimal data they are required to perform their function. Complimentary to access controls are audit logs: produce audit logs of who accessed the data, at what time etc. Another example of roles and privileges is separation of duties; in the financial world one might ensure that the person who makes out a check cannot sign it, thus preventing a dishonest user of making a check out to themselves or their friend.
In the financial world the concern is that a user who accesses and modifies data without authorized access and privilege may use that data illegally. For example, a hacker who steals credit card numbers from the database of an online merchant and then performs purchases with those credit cards. Similarly in the United States, social security numbers can be stolen to create fake personal identities.
Implications for digital patient information stored in electronic health records or similar.
US regulations require that entities disclose breaches of electronic health data, as highlighted by Lisa Gallagher.
The security policy for an Electronic Medical Record that contains Personal Health Information consists of three entities:
1. Subject – the patient. Though the subject may require an agent, for example the agents of a new born baby are its parents; a living will can stipulate that an agent make decisions on behalf of an incapacitated person.
2. PHI – Personal Health Information – the actual medical and personal data about the patient.
3. Clinician – The physician treating the patient.
Theft of personal electronic medical data can be used for nefarious financial purposes, such as billing medicare for service not rendered. However, I believe there are greater risks as follows:
- Integrity – are we certain that this data belongs to this patient.
- Confidentiality – prevent data from posted to the Internet
- Access
It is paramount that data in electronic medical records is never overwritten or deleted only appended.
Auditors should only access a copy of a patient’s record, never the original so that they do not alter or append data.
A physician should have the privilege to alter access to an electronic record. Example, a patient is referred from a family physician to a specialist, thus the family doctor grants the specialist access to the patient’s medical record. At all times the patient should know who has access to his/her medical record.
Exceptions to these access rules:
- In an emergency access may be granted to someone other than the subject (patient or their agent).
- Court ordered access to a medical record.
However, a conflict of interest scenario is possible, a medical practitioner hacks into an EMR and faxes prescriptions for themselves.
In closing, HIMSS conducted a survey, sponsored by Symantec, of security policies and procedures in place at medical institutions.
Federated Identity for Electronic Medical Records
I read with great interest this posting by Adrian Gropper on The Health Care Blog, which was referenced by PracticeFusion’s blog entry on HIT interoperability.
Adrian describes the true case of a soldier injured in Afghantistan and then the hypothetical case of the soldier (or a delegate on his behalf) accessing his personal health record in government and private healthcare providers. The basic premise is that patient only needs to authenticate once to a trusted identity source, thereafter the patient is granted access to their medical record. This is a sample use-case of Federated Identity, already in use in web applications. Adrian Gropper references OpenId. While that is an example of Federated Identity, the security protocols do not lend themselves towards the access and privacy requirements of medical records.
Firstly, to explain Federated Identity, I offer the following analogy. The European Union (EU), is a trans-national or umbrella organization with member States such as France, Spain, Belgium. Citizens of member States are issued EU passports and may thus travel freely within the other EU member States without requiring visas. The passport official at the airport or frontier, will recognize and trust the EU passport, but will verify that the bearer of the passport matches the identity in the passport before granting entrance to the individual. Once that individual enters the country they are entitled to services or privileges granted to them, such as tourism or employment, but other privileges may be denied, as they are member State specific, such as retirement benefits. These privileges differ depending who the user is, a visiting head of state may have higher privileges than an ordinary citizen.
Authentication: The process of matching the identity of the person to the identity claimed in the passport. In computer speak – proving who you are before you can use a computer application.
Authorization: The process of granting services to the person, based on their privileges. In computer speak – once authenticated, your attributes or role determine what functions of an application you are entitled to use.
In Adrian’s example of an injured soldier accessing their health-record maintained by different health-care providers, the following Federated Identity infrastructure exists:
- A central Identity Provider (IdP) (analogous to the EuropeanUnion) who’s role is to issue and revoke digital identities.
- Healthcare providers, ServiceProviders (SPs), (analogous to EU member States) who provide a service, in this case manage an Electronic Medical Record.
- Trust relationships between SPs and IdPs. For example, military hospitals, private hospitals, HMOs, physicians etc establish trust relationships with the Identity Provider. These trust relationships usually entail (a) legal/paperwork agreements and (b) technical exchanges to enable identity certification.
This infrastructure enables the following scenario:
A user of any (Healthcare) ServiceProvider, who has been issued a digital identity by the trusted IdentityProvider, may seamlessly interact with the healthcare providers (SPs). The user will present the digital identity issued by the IdP, the SP will verify the Identity, and the user will be granted access to the Service Provider’s application. However, based on the user’s attributes and role, the functionality available to the user will vary. A physician may alter a medical record but only within their specialty ( a dermatologist cannot alter a prescription for spectacles). A pharmacist may view but not alter the prescription for insulin in a healthrecord. A patient may only view but not alter their medical record. In Adrian’s example, the soldier may view his medical record and perhaps authorize it’s transfer to another care provider.
The following provides a graphical view of Federated Identity with the European Union as an analogy and a patient as sample user.
Who owns the patient data?
When a new medication is developed, pharmaceutical companies conduct a clinical trial: a controlled study of the effect of a medication on selected group of volunteers, perhaps 1000.
Imagine if the benefits and side effects of a new medication could be gauged from not a thousand people but one million of all ages, genders, races and who may or may not already have other diseases complications and may or may not be taking other medications.
One of the benefits of electronic health and medical records is there are vasts amounts of data to be mined and analyzed. Anonymize the patient data and you can create statistics and analysis of the effects of medications, diseases and treatments.
But who owns that patient data? In speaking with a relative of mine who is a physician, he told me that certain very large medical institutions will not release their valuable data for other researchers to use and analyze. They consider that patient data their intellectual property, their treasures.
I posit that the data belongs to the patient, that the patient should be able to control who can access that data even if it is anonymized. The patient, using HIPAA guidelines, should be able to control who has access to his/or her data and not the medical institution.
About
Simply passionate about Healthcare Information Technology and Informatics.
Located one mile from Stanford Hospital, California.
Looking forward to the conversation
Jonathan Gershater; email: jogershater’AT’pacbell.net
Subscribe to this blog
-
Archives
- June 2010 (1)
- May 2010 (2)
- March 2010 (9)
- February 2010 (4)
- January 2010 (4)
- December 2009 (6)
- November 2009 (5)
- October 2009 (9)
- September 2009 (16)
- November 2008 (4)
- October 2008 (2)
- March 2008 (1)
-
Categories
-
RSS
Entries RSS
Comments RSS
