Software Associates specializes in helping medical device and healthcare technology vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.
As I noted here and here, the security and compliance industry is no different from other industries in having fashion and trends.  Two years ago, PHR (Personal Health Records) systems were fashionable and today they’re not – probably because the business model for PHR applications is unclear and unproven.
Outside of the personal fitness and weight-loss space, it’s doubtful that consumers will pay  money for a Web 2.0 PHR application service to help them store  personal health information especially when they are paying their doctor/insurance company/HMO for  services. The bad news for PHR startups is that it’s not really an app that runs well on Facebook and on the other hand, the average startup is not geared to do big 18-24 month sales cycles with HCP (health care providers) and insurance companies.  But – really, business models is the least of our problems.

There are 3 cardinal  issues with the current generation of EHR/EMR systems.

1. EHR (Electronic Health Records) systems address the business IT needs of government agencies, hospitals, organizations and medical practices, not the healthcare needs of patients.
2. PHR (Personal Health Records) systems are not integrated with the doctor-patient workflow.
3. EHR systems are built on natural language, not on patient-issue.

EHR – Systems are focused on business IT, not patient health

EHR systems are enterprise software applications that serve the business IT elements of helthcare delivery for healthcare providers and insurance companies; things like reducing transcription costs, saving on regulatory documentation, electronic prescriptions and electronic record interchange.¹
This clearly does not have much to do with improving patient health and quality of life.
EHR systems also store large volumes of information about diseases and symptoms in natural language, codified using standards like SNOMED-CT². Codification is intended to serve as a standard for system interoperability and enable machine-readability and analysis of records, leading to improved diagnosis.
However, it is impossible to achieve a meaningful machine diagnosis of natural language interview data that was uncertain to begin with, and not collected and validated using evidence-based methods³.

PHR – does not improve the quality of communications with the doctor

PHR (Personal Health Records) on the other are intended to help patients keep track of their personal health information. The definition of a PHR is still evolving. For some, it is a tool to view patient information in the EHR. Others have developed personal applications such as appointment scheduling and medication renewals. Some solutions such as Microsoft HealthVault and PatientsLikeMe allow data to be shared with other applications or specific people.
PHR applications have a lot to offer the consumer, but even award-winning applications like Epocrates that offer “clinical content” are not integrated with the doctor-patient workflow.
“Today, the health care system does not appropriately recognize the critical role that a patient’s personal experience and day-to-day activities play in treatment and health maintenance. Patients are experts at their personal experience; clinicians are experts at clinical care. To achieve better health outcomes, both patients and clinicians will need information from both domains– and technology can play a key role in bridging this information gap.”⁴

 EHR – builds on natural language, not on patient issues

When a doctor examines and treats a patient, he thinks in terms of “issues”, and the result of that thinking manifests itself in planning, tests, therapies, and follow-up.
In current EHR systems, when a doctor records an encounter, he records planning, tests, therapies, and follow-up, just not under the main entity, the issue. The next doctor that sees the patient needs to read about the planning, tests, therapies, and follow-up and then mentally reverse-engineer the process to arrive at which issue is ongoing. Again, he manages the patient according to that issue and records information, but not under the main “issue” entity.
Other actors such as public health registries and epidemiological researchers go through the same process. They all have their own methods of churning through planning, tests, therapies, and follow-up, to reverse-engineer the data in order to arrive at what the issue is.
This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the patient
• No sufficient connection to clinical guidelines, no indication on which guidelines to follow or which have been followed
• No connection between prescriptions and diseases, except circumstantial
• No ability to detect and warn for contraindications
• No archiving or demoting of less important and solved problems
• Lack of overview of status of the patient, only a series of historical observations
• In most systems, no sufficient search capabilities
• An excess of textual data that cannot possibly be read by every doctor at every encounter
• Confidentiality borders are very hard to define
• Very rigid and closed interfaces, making extension with custom functionality very difficult