Electronic health records, historically, have always been provider-centric. Providers, by definition include medical providers, clinics, or hospital entities. EHR’s are housed and maintained by the provider and the data is “owned” by the provider itself (although sometimes that is debatable depending on what type of EHR vendor you use). As an extension of this, all billing is done in a provider-centric way and historically, EHR’s were an extension of an existing practice management system framework.
But one of the main stumbling blocks of such a system of siloed provider-centric electronic health records is interoperability. Even with “open standards” such as the C-CDA, vendors have different “versions” which render the whole idea of interoperability a joke. If a patient goes to one provider with one EHR, but doesn’t talk to another provider with another EHR, imagine the potential problems this would be. Lab test results, past documentation and hospital visits are not ideally centralized. This potentially leads to ineffective and inefficient use of health care resources. This leads to, at best, duplication of treatments and testing and at worst, causing harm if there was an undocumented allergy (for instance) that didn’t get transferred from one EHR to another. Interoperability could have come a long way had Meaningful Use focused on this rather than doing “un-meaningful” approaches to encourage physician adoption to use an EHR. So, I don’t see this as being a reality or being addressed any time in the near future.
But what if we turned the framework upside down (in the patient-provider relationship) and make the EHR patient-centric?
In a patient-centric EHR scenario, the patient would house and/or maintain the EHR for the patient and the data is “owned” by the patient. Any provider who sees and treats the patient would input the data into the patient-centric EHR, thereby centralizing all the up-to-date data in one place, available, all the time.
In a patient-centric EHR scenario, this would take the concept of OpenNotes one step further (which, by the way, NOSH already has functionality for through it’s patient portal feature).
As I was developing NOSH as a provider-centric electronic health record that happens to have a patient portal, I didn’t initially realize that the foundations I set for the NOSH code and database schema, especially now that it has been cleaned up with nice Laravel code, is also primed for a patient-centric EHR. All that it needs to operate NOSH as a patient-centric EHR is the installation routine where the practice is not set initially, but the patient itself. Because NOSH was not developed from a practice-management billing system, it’s very easy to decouple and reuse the existing code to make the transition into a patient-centric EHR very easy.
Furthermore, to limit the impact on non-clincial provider workflows such as billing, supply inventory, and population health analytics (which NOSH already handles out of the box), the provider would then install a NOSH version that remains provider-centric in the sense that it has a way to access all of their patient’s NOSH accounts through a provider ID (say the NPI number) and secured through a secret key associated with that provider ID which would then automatically input the provider’s data/practice into patient’s NOSH once and authorized by the patient.
So in essence, there is a patient NOSH and a provider NOSH and they would interoperate cohesively. To recap, these are the potential benefits of a patient-centric EHR:
- No interoperability issues
- Centralized medical health information, including C-CDA’s
- Limit duplication of treatments and tests
- Potential cost-effectiveness of care
Of course, no idea comes without its challenges:
- Potential extra work for providers to enter their practice information for a new patient. However, having the API’s to connect between the patient and provider-centric EHR’s should mitigate this barrier. Having well-documented APIs and keeping them open (through open source licensing such as NOSH) and non-proprietary from the patient-centric point of view should allow current and legacy EHR’s to connect for those who have already bought into expensive EHR technologies. The idea of a strict, but open, API versus an open standard like a C-CDA is that the API approach literally guarantees interoperabilty if EHR’s or practice management systems choose to play nicely.
- Existing technologies for ancillary medical services (lab, pharmacy) may need to be reconfigured for each provider. However, with the recent HIPAA ruling going into effect currently, lab providers must allow patient access to the lab results. Should this be done through a patient portal of sorts provided by the lab service, a patient-centric NOSH could then scrape that information, stored in the patient-centric NOSH with API access from the provider. This may be an efficient workaround, bypassing the current hodgepodge of expensive, proprietary connections between various lab providers with legacy EHR’s.
- This system is only as good as the percentage of healthcare providers that adopt and use it. Current mandates through Meaningful Use achieved increased EHR adoption (primarily in the hospital and academic realm), but many physicians in both the inpatient and ambulatory realms are quite upset with the choices they have to make with lackluster user interfaces and significant disruptions to workflow and productivity, and unrealized return of investment. The backlash was quite predictable. However, offering an alternative avenue through positive patient engagement, especially with the youth and young-adult sector who are quite tech savvy , this may provide a non-punitive, non-paternalistic method of electronic patient record documentation adoption.
This positive, virtuous cycle, with the patient-centric EHR as the core foundation, would be this:
Patient signs up for a patient-centric EHR that is housed in a secure, cloud based server.
Patient goes to Doctor who may or may not have an EHR.
Patient asks Doctor to enter his encounter documentation into the patient’s EHR.
If Doctor has NOSH already, patient provides an encrypted API key to Doctor to access patient’s NOSH. Doctor associates this encrypted API key to the patient’s NOSH chart and any notes generated on Doctor’s NOSH automatically is synchronized with patient’s NOSH.
If Doctor has EHR “X”, and the EHR doesn’t have a way to send information via the patient NOSH API, Doctor has several options:
- Enter into patient’s NOSH anyways through a secure sign on process and bypass his current EHR. Doctor would then just enter billing information into EHR “X”. Doctor might feel compelled to ask his EHR “X” to create code to access the patient NOSH API and point to the documentation provided to synchronize information between EHR “X” and patient NOSH to make Doctor’s life easier.
- Doctor could ditch his old EHR completely (if the Doctor can do it without going broke) and adopt NOSH in the Cloud or set up NOSH on-site for his own practice.
- Doctor could just install a basic practice management system and not have to keep any patient documentation on site however, this would limit Doctor’s ability to do any healthcare analytics for the practice.
If Doctor says “No, I don’t want to put my encounter documentation into your EHR”, the patient would likely say, “Then I’ll go somewhere else.”
The one benefit that NOSH can provide as a provider-centric EHR is the fact that the client user interface (either a provider or the patient) can be accessed by any device or operating system as long as there is a modern web browser and an internet connection. Housing the patient-centric NOSH service could either be a cloud-based solution versus a low-cost, portable, appliance that the patient would have to maintain. Being open-source allows peer review of the code to provide continuous improvement to the system and it would carry all the benefits of having provider-specific templates. After all, being an open source licensed and non-certified EHR, NOSH is free to move into a patient-centric EHR domain, if it’s feasible without major reworking of the code.
Very soon, these ideas will become a reality. Does anyone have any thoughts or any thing to add to the benefits and challenges list? Feel free to make a comment!