[Openid-specs-heart] Recap of HEART meeting 5/16/16 on a non-data-blocking self-assertion label: Foo

[Josh Mandel]

Hi Adrian,

While we haven't yet received minutes from yesterday's call, I feel
compelled to point out that much of the discussion on yesterday's call felt
(to me) more like the HEART workgroup members asking detailed questions in
an attempt to understand what you were actually proposing.

To the extent that the group could follow, your proposal appeared to
require the creation of new standards, rather than the profiling of
existing standards — and to that extent, it appeared out of scope for
HEART. At least, that was my take-away from the conversation around the
4:45pm ET mark; I don't mean to speak for the group.

I think the action item at the end of our call was for you to write up
something more formally so the group could take another shot at trying to
understand it and determine whether it falls within HEART's charter. Eve
shared some specific advice, which I hope you will follow: please try to
dial back the technical recommendations in your write-up (things like "we
need public key encryption of the Request Form" and "we need the FHIR
Subscription API") and instead focus on your motivation (i.e., your desired
functional properties) so the technical team can try to propose approaches
that might be a good fit.

Best,

 Josh



On Mon, May 16, 2016 at 11:01 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Thanks to all for a very friendly and constructive discussion of a label
> ("Foo" for now) that any two FHIR endpoints can self-assert to indicate
> that "Independent Decision Support at the Point of Care for Physicians and
> Patients" is supported. Done right, this could eliminate all sorts of
> regulatory mandates and certifications.
>
> Much of the call was about what standards or profile groups would be
> appropriate to define Foo and how much of that would be in-scope for HEART.
> Foo would start by requiring support for the existing FHIR Subscription and
> History features at the patient-level. We also discussed if UMA or other
> current Kantara projects could be adapted to the definition of Foo.
>
> During the call it was proposed that FHIR-based interoperability labels
> need to handle maybe 5 different health records architectures:
>
>    1. Centralized EHR (inpatient and outpatient as in, maybe Israel)
>    2. Decentralized EHR (central inpatient, distributed outpatient, as in
>    UK)
>    3. Patient Centered EHR Summary (centralized and patient-controlled,
>    as in AU My Health Record)
>    4. Patient Owned EHR (distributed to each patient, as in Apple
>    HealthKit, ResearchKit, and CareKit)
>    5. EHR Apps and Independent Decision Support (user-interactive)
>
> Given that FHIR EHR endpoints might be participating in any and all of the
> 5 patterns (the physician or the patient as requesting party could be on
> either side of the FHIR transaction) does Foo apply only to some or all of
> the 5 architectures? I propose that a single Foo can cover all 5 and
> provide a clear objective goal for all of the various standards and data
> blocking measures.
>
> We concluded with a suggestion that Foo might be documented as a new HEART
> Use Case over the next few weeks.
>
> Adrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160517/66d021b9/attachment.html>