[Openid-specs-heart] EHR, PHR, FHIR resources.

Wed Nov 18 14:40:46 UTC 2015

I had to google Serpico…. And Adrian even looks like Serpico! ☺

I hope his vision comes to fruition in my lifetime too, so that patients and their health can finally be at the center.

Thanks,
Ileana

Ileana Balcu
(732) 744 1116 x 103

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Aaron Seib
Sent: Wednesday, November 18, 2015 8:21 AM
To: 'Adrian Gropper' <agropper at healthurl.com>; 'Glen Marshall [SRS]' <gfm at securityrs.com>
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] EHR, PHR, FHIR resources.

Serpico, Serpico, Serpico.

I hope your vision comes to fruition in my lifetime so you can prove everyone else wrong.

Aaron Seib
NATE<http://www.nate-trust.org/>, CEO
@CaptBlueButton
(o) 301-540-2311
(m) 301-326-6843

From: agropper at gmail.com<mailto:agropper at gmail.com> [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Tuesday, November 17, 2015 11:13 PM
To: Glen Marshall [SRS]
Cc: Aaron Seib; openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] EHR, PHR, FHIR resources.

The BLT (Business / Legal / Technical) discussion that is implied in this thread depends on your perspective. EHRs and PHRs are an invention of institutions that see patients as a source of revenue and their information technology as a Materials Resource Planning (MRP) function designed to efficiently and profitably schedule what the patients, clinicians, and staff do. That the EHR systems help with billing and regulatory issues is a bonus. The interoperability aspect of the EHR is all about MRP as well. The PHR (tethered or not) is, from the institutional perspective, just another kind of interoperability and needs to be managed for efficiency and profit.
From the patient perspective, the EHR / PHR model is, IMHO, a disaster. It introduces barriers to second opinions and access to innovative services, makes outcomes measures procedural and institutional instead of personal, supports secret contracts between provider institutions and payers, and makes us doubt whether our doctor is working for us or for "them".
HEART does not need to take sides in the institutional vs. patient-centered information technology struggle. We can hope that HEART supports the patient-centered model as much as it does the institution-centered model. This is not a philosophical distinction. Our standards and profiling decisions will determine whether an institution can block access to your personal data by other people, systems, or apps that the institution decides are "insecure" or "unsafe".
What is "insecure" or "unsafe" is debatable. What is data about me and only me is clear, as is my right to a convenient and effective connected FHIR copy of my own data. The way for HEART profiles to serve both the patient and institutional perspectives is to:

  *   allow for the institutions to put up "black box" warnings if they disagree with our choice of people, systems, or apps, and
  *   allow the patient or their agent to connect anyway after they have seen the "black box" warning.
The HEART profiles will support this by providing for:

  *   unrestricted patient-specified Authorization Servers,
  *   Dynamic Registration of connected systems, and
  *   ways for the FHIR interface to bypass information delays (allowed by HIPAA) when the patient has delegated access to a licensed clinician or a physician says the delays are not appropriate, and
  *   strong "safe harbor" protections for the institutions when they release the FHIR interface under this "patient's right of access".

This is the minimum for enabling HEART to support both patient and institutional perspectives and it's the essential enabler for the next generation of practice and payment reform.

Adrian

On Tue, Nov 17, 2015 at 10:20 PM, Glen Marshall [SRS] <gfm at securityrs.com<mailto:gfm at securityrs.com>> wrote:
Aaron,

Thanks for the clarification.  I thought it was systems that were tied to one another, not the patient being tethered.

At latest count I have 7 "tethered" patient portal accounts, none of which communicate with each other nor with my PHR account.  Quest is a happy exception.

Glen

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452<tel:%28610%29%20644-2452>
Mobile: (610) 613-3084<tel:%28610%29%20613-3084>
gfm at securityrs.com<mailto:gfm at securityrs.com>
www.SecurityRiskSolutions.com<http://www.SecurityRiskSolutions.com>
On 11/17/15 21:15, Aaron Seib wrote:
Hi Glen – I like your definition but in the domain of Consumer Facing Applications that includes both tethered and untethered PHRs and other apps controlled by the consumer we use the term tethered in a much more narrow way.

A tethered PHR is what is typically encountered as a Patient Portal of an EMR.  The only data that is viewable via such a portal is what is created within the EMR and made viewable to the consumers’ accounts.  MicroSoft HealthVault on the other hand is not “tethered” to a single source of data but is untethered and may receive data from multiple data providers including for example data from the different EMRs used by your Doctors, the several labs and yes – even the Patient Generated Health Data entered by you.

Like most things in the sphere of language the usage changes the meaning but I have found constraining the use of tethered to mean a portal that is a view into a single enterprises view very useful from a policy discussion perspective.

Essentially if you offer your patients a portal that is a Tethered PHR and the operator of that Tethered PHR signs a BAA with you then the system should be treated as you would any HIPAA covered system.

An untethered Portal, where the consumer has control over what data is added (via different modes of exchange) is not a HIPAA covered system but falls under the regulatory requirements of the FTC.

The distinction is often important.

As time goes by we are seeing these lines blur but at least for now they are useful in my little slice of the world.  In your example below I would say that Quest is sharing your Lab results by one of the modes of exchange supported by MSHV – guessing Direct?

Aaron Seib
NATE<http://www.nate-trust.org/>, CEO
@CaptBlueButton
(o) 301-540-2311<tel:301-540-2311>
(m) 301-326-6843<tel:301-326-6843>

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen Marshall [SRS]
Sent: Tuesday, November 17, 2015 7:38 PM
To: openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] EHR, PHR, FHIR resources.

Dale,

A personal example may suffice...

I have a Microsoft Health Vault account.  It is my PHR.  It includes data that I have entered and maintain, e.g., current demographics, medications, allergies, health events, visits, etc.  It also automatically obtains lab results from Quest Diagnostics, which is "tethered" to it.  I am hoping that my personal physician's EHR will soon be able to be tethered so I don't have to keep manual track of it.  In lieu of automatic tethering, though, I can import data from patient portals to my regular family doctor, my urologist, radiological images, blood glucose meter, etc.

Glen

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452<tel:%28610%29%20644-2452>
Mobile: (610) 613-3084<tel:%28610%29%20613-3084>
gfm at securityrs.com<mailto:gfm at securityrs.com>
www.SecurityRiskSolutions.com<http://www.SecurityRiskSolutions.com>
On 11/17/15 17:52, Dale Moberg wrote:
Hi

I am still refining my grip on assorted terminology that reveals aspects of the “business model” contexts for discussing our use cases.

I just read the wikipedia entries for PHR and EhR (I know, but you have to start somewhere), at
https://en.wikipedia.org/wiki/Personal_health_record  and
https://en.wikipedia.org/wiki/Electronic_health_record

Nominally viewed, there appears to be substantial intersections of the resource types (in a loose FHIR usage) found in these EhR and PHR records.

At https://en.wikipedia.org/wiki/Personal_health_record#EHRs.2C_PHRs.2C_patient_portals_and_UHRs it is maintained that the “ownership” of the records is the primary semantic contrast between the terms. Interesting.

I am particularly even more motivated in getting some information about the following statement:

"There are two methods by which data can arrive in a PHR.[1]<https://en.wikipedia.org/wiki/Personal_health_record#cite_note-Tang-1> A patient may enter it directly, either by typing into fields or uploading/transmitting data from a file or another website. The second is when the PHR is tethered to an electronic health record, which automatically updates the PHR.”

Does anyone know the “BLT” pertaining to the “tethering” process? Is this tethering something that is currently actually in operation, or is it mainly imagined as emerging once FHIR dstu-X is completed? (And maybe UMA and HEART completed also?)

 (Adrian offered to help some of us with the terminology, so I am taking him ( and anyone else) up on the offer!)

Dale Moberg

_______________________________________________

Openid-specs-heart mailing list

Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs-heart

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151118/37934275/attachment-0001.html>