Josh Mandel jmandel

Let me search for data on legitimate use cases where patients share their full EHR with third parties.## Legitimate Patient Use Cases for Sharing Full EHR: Economic Analysis

Based on my research, here's a comprehensive analysis of legitimate use cases where patients would share their full EHR and the economic implications:

Major Use Cases & Market Sizes

1. Social Security Disability (SSDI/SSI) Applications

Annual Volume: ~2-2.5 million applications filed annually
Medical Records Need: Many states waive or limit fees for disability claims, with free copies for SSI/SSDI claims
Current Process: Manual requests, paper forms, state-specific pricing

Farzad (0:00) Josh, we started working together 15...

Josh Mandel (0:06) Yeah, yeah, early days of SMART.

Farzad (0:10) Yeah. And we, at the National Coordinator for Health IT, we had some nice assets for research and development and one of the 15 R&D projects we funded ended up having the biggest impact, which was the SMART project at Harvard and Josh was there and has always impressed me with his generosity, his ability to go deep, but then also to share what he has learned. And we saw Josh as per usual, on the outward edge of looking at, in this case, some of the model context protocols and he's generously agreed to come and share with our team some of what he's learned, but also for us to explore together where, where might this technology lead us both in terms of policy as well as implementation. Maybe the team can quickly introduce themselves and their roles and then I'll turn it ov

Subscribers and dependants

Minimum bar: support patient/ scopes (e.g., patient/ExplanationOfBenefit.read), and authorize the app for each patient record. So here at authz time, e.g., scope=launch/patient patient/ExplanationOfBenefit.read patient/Coverage.read ... e.g., scope=launch/patient patient/*.read

Beyond the minumum, a server can support user-level scopes ("do you want to share all the records you have access to with the following app"...)

Background: Consumer API Access via Certified EHR APIS

In a series of EHR Certification and Meaningful Use programs since 2010, US national policy has driven toward better consumer access to clinical data – first through online portals; then through downloadable documents; and most recently through APIs that enable third-party application access. This technology is enabling consumers to connect apps like Apple Health or MyFHR to their health records, helping individuals understand their health and shop for better care. API access is expanding, but key struggles include:

App registration does not scale. Today, connecting an app requires not only permission from a patient, but also (as a pre-requisite), two additional hurdles that limit the ability for apps to scale: registration with an EHR vendor and approval by a healthcare provider organization. These two steps mean that apps must seek approvals from institutions that may not share common values or business incentives. The first hurdle should be

Automated captions for https://www.youtube.com/watch?v=LEfgVrzwipw

I wanted to spend a few minutes, and introduced some vocabulary around a few court challenges in managing identity in healthcare and beyond. I want to argue that today. Things are pretty broken. Even when they seem to be working kind of OK and then point forward to a set of emerging specifications that are the first thing I've seen in a long time that really look like they could actually make a dent in the problem.

I think a little bit about a road map towards getting there so to start I want

	javascript:(function() {
	function findNearestParentWithAttribute(node, attr) {
	while (node) {
	if (node.getAttribute(attr) !== null) {
	return node;
	}
	node = node.parentElement;
	}
	return null;
	}

	{
	"resourceType": "ImmunizationRecommendation",
	"patient": {
	"reference": "resource:0"
	},
	"date": "2013-05-13",
	"authority": {
	"display": "Lone Star Immunization Registry"
	},
	"recommendation": [

	example.pypf

	Example measure report (pseudo-yaml-pseydo-FHIR)(TM)
	----

	resourceType: MeasureReport
	status: complete
	type: summary (??)
	measure: https://audaciousinquiry.github.io/saner-ig/Measure/bed-availability-measure
	date: today

	{
	"resourceType": "Bundle",
	"id": "handshake",
	"type": "history",
	"timestamp": "2019-08-07T10:24:13.1882432-05:00",
	"meta": {
	"extension": [
	{
	"url": "http://hl7.org/fhir/StructureDefinition/subscription-event-count",
	"valueInteger64": "0"

	{
	"resourceType": "Bundle",
	"type": "searchset",
	"total": 3,
	"link": [
	{
	"relation": "self",
	"url": "https://fhir.careevolution.com/Master.Adapter1.WebClient/api/fhir-r4/ExplanationOfBenefit?patient=d4b1d050-584f-4797-a9c7-ab72e4cd4452&_count=20"
	},
	{