Our team has built a Personal Health Record platform that connects patient portals, US Medicare Blue Button claims, and health insurance summary info. We use HL7 international standards as much as possible, but it’s really a US based tool for now.
We’d love people to try it out and give feedback - we’re mostly interested in prioritizing new features so let us know what you’d like us to add next.
Bonus points if you are over 65 and can connect your MyMedicare.gov account to see your Parts A, B, and D claims alongside a patient portal.
When you sign up, we’ll give you a 7 day premium coupon. If you’re interested in using it longer term, send me a message and I can get you a longer coupon.
Hi John, Thanks for posting here, I think it’s interesting to see an Epic PHR, and I’m curious how it all works. I went through the privacy policy and noticed that it’s mandatory to allow Epic/Blue Laurel to allow sharing of all personal data with insurance companies. Why is this mandatory?
Hi Gary, thanks for the review and question. A few notes about this …
Our model is designed to better connect the broader system. We believe that patients are vastly underserved so we’re starting there. Our background is in the insurance industry, so we understand the use cases that insurers have to already get your records. We’re just trying to be another source, while also providing value to patients directly.
It’s important to note that we would only share with a users current health insurer. Nothing is forcing a user to link their insurance - in which case, we wouldn’t share the data with any insurer. We do provide value for establishing that link, namely providing up to date deductible and out of pocket spending (more info here).
In the future, we’re planning to build in data level privacy which would enable a user to hide certain data - e.g. the fax fro Dr. Jones, a certain medication, or a certain procedure).
These are important topics and we believe it’s important to have an open dialogue about them. Please let me know if you have additional questions.
Hi Eric, I can share credentials for a dev account below, with a few caveats that you might expect…
Since we pull data from various sources, the synthetic data don’t match up internally. For example, the procedures from the patient portal sandbox don’t reconcile to the Medicare claims sandbox.
Even within one source, some of the data are silly. For example the Insurance / Claims / Providers are all “unknown” because of how we get that sandbox data, whereas a real Medicare beneficiary would see their doc’s real name there.
Please do not put any PHI in there (I know that’s not your intent). On a related point, the faxing feature doesn’t go anywhere - to protect against providers faxing into the demo.
You can see the insurance checking feature, but it won’t work to put in your own because (like the other services) the demo account is not turned on for production data.
I suspect many on this forum may be interested in inputting your own data / vitals, etc… As discussed earlier, that’s not turned on yet, but it’s on the list and we’d like to know if that is of interest to add soon rather than later.
While I support kicking the tires in the demo account, I reserve the right to shut down that account if others see the credentials and abuse it.
Lastly, our site is free to try and we’ll give a coupon for premium, so you can set up a prod one when you’re ready (note the different subdomain).
Feel free to test it out a completed account below:
[REDACTED - DM me if interested]
You’ve found your way to a corner of the Internet where basically the only focus is self-tracking data. (Or “PHI” from the healthcare perspective.) I get that the main action in commerce and infrastructure is in the healthcare informatics domain; in a world of multi-hundred billion dollar insurance companies, there’s not very much incentive to design for individual access and discovery. BUT, if and when this does become a priority, some features that would be useful are:
A private data store accessible only the the individual who created it, and not shared with any third party without permission. It’s important that no exceptions be made for aggregated and so-called “de-identified data.”
User defined data types.
Best practices for resolving time stamps of data collected, including time zone offsets.
Queryable in detail, ideally down to the level of the individual observation.
Best practices applied for maintaining data provenance, which in our use cases can mean preserving a record of what instruments were used in the data collection, at whatever detail they’re available, including firmware info.
A system that offered even some of these benefits would be very interesting to evaluate!
Thanks for the feature input. Many of these have been in our backlog, and we’re open to re-evaluating the priorities.
I’m wondering if you (or others watching) can elaborate on #2 - user defined data types. Could you provide a few examples (or even threads here) for us to research so that we build for a broad set of use cases?
As we release features relevant to this audience, I’ll append to this thread as we’re always looking for testers.
The reason user defined data types is important is that there are so many different things people may want and need to track to learn about consequential personal questions. A good way to get a snapshot of this diversity is to browse the Show&Tell archive on this site. It’s pretty remarkable to see the range. Two quick examples:
Some QS participants who are tracking things to help manage Parkinson’s disease have talked about tracking “feel good time.” Because the disease has such a wide range of symptoms, including drug side effects, it’s more meaningful to them to track when they are able to function and feel reasonably well, rather than to track a specific physical phenomenon.
Many people care about the food they eat, and some projects involving the relationship between food and health are very important for managing medical conditions. Look at the comments in the recent JAMA issue about N-of-1 practice in medicine for a great example involving dairy and esophageal pain. Medically oriented record systems typically ignore diet tracking, which involves quite a bit of personalization, despite the fact that this may be a key part of what’s happening through a course of treatment.