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

Eve Maler eve.maler at forgerock.com
Sun Dec 13 21:50:24 UTC 2015 

(Wow, Serpico... Adrian does totally look like him.)

This thread took place mostly during my vacation, and I'm finally digging
down to the bottom of the unread emails after the latest spate of travels,
so please forgive the unearthing of the old thread. I just wanted to point
people to relevant term definitions appearing in our first use case
regarding tethering, to perhaps come full circle on this:

HEART Use Case: Alice Registers with PCP and Sets Up Two-Way Exchange of
Personal Data Between EHR and PHR [OAuth Only]
<https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit?usp=sharing>

Under the *Ecosystem parties* section:

   - Primary care provider (PCP): a health care professional who will see
   Alice on a regular basis for common medical concerns; end user of an
   electronic health record (EHR) system, an enterprise Internet-facing
   information system that tracks many patients’ medical information, and has
   a patient-facing portal. This document uses “portal” exclusively to refer
   to a “tethered” type of PHR to avoid confusion.
   -
   - Personal health record (PHR) system operator: a provider of a PHR
   system, a private Internet-facing information system that tracks Alice’s
   medical information for her where Alice is the end user with authority over
   her data, and where the PHR system operator supports many such end users.
   This document uses “PHR” exclusively to refer to a “patient-controlled” or
   “untethered” type of PHR to avoid confusion.

The very nature of OAuth technology is to enable the "joining together" of
an API and a client application, e.g., for the automatic exchange of data
as authorized by someone who controls access rights to that API. One might
be tempted to say "tether", but at that point in our use case development,
we agreed not to.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Wed, Nov 18, 2015 at 6:40 AM, Ileana Balcu <ibalcu at dulcian.com> wrote:

> I had to google Serpico…. And Adrian even looks like Serpico! J
>
>
>
> 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 <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
> *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>
> 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
> Mobile: (610) 613-3084
> gfm at securityrs.com
> 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
>
> (m) 301-326-6843
>
>
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <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
> *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
> Mobile: (610) 613-3084
> gfm at securityrs.com
> 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
>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> 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/
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151213/6aadc216/attachment.html>

More information about the Openid-specs-heart mailing list