<div dir="ltr"><p class="MsoNormal"><b>Attendee Stats</b></p><p class="MsoNormal"></p><ul><li>16 in attendance 9 are members - ( Attendee roster link avail next week)<br></li><li>Listserv up to 87 members (wow!)<br></li></ul><p></p><p class="MsoNormal"> </p>
<p class="MsoNormal"><b>Virtual
Patient Registration Use Case - ( </b> <a href="http://hg.openid.net/heart/wiki/Virtual_Patient_Registration">http://hg.openid.net/heart/wiki/Virtual_Patient_Registration</a> <b>)</b></p>
<p class="MsoNormal"></p><ul><li>Catherine
Schulten presented the Virtual Patient Registration use case, based on Virtual
Clipboard from the WEDI effort. The idea is that the patient can bring their
eligibility data (the 270 X12 eligibility request) to the equation. The use
case being displayed takes a different twist; it meets the needs of the patient
stakeholder, the provider stakeholder, and also the payer stakeholder.<br></li><li>The
individual is a “patient” to the provider, and a “subscriber” to the payer. The
individual may be a child, or an elderly person who may give someone else their
proxy for parts of the flow. The data used in registration is part of a
familiar form. The “top of the form” has familiar identification and location
fields. Then you get into insurance information. And then medical
history/clinical information. This use case focuses most on the “top of the
form” (financial and administrative data), not on the clinical information.<br></li><li>The
registration event sparks a lot of downstream processes. People ask you for all
this data in order to support further population of healthcare claims, clinical
application processes, filling out of names on the tops of charts, and so on.
It touches lots and lots of systems. So it’s important to get it right at the
beginning.<br></li><li>The
actors include a healthcare provider, a healthcare payer, and a patient.
You fill out the form to the best of your recollection. Someone transcribes
written text into a computer system. Other transactions get spawned off of
this. There’s an e-registration service that would let the patient create a
profile and allow systems to accept the e-registration process. The patient and
the provider would need to be “known to the service” somehow, kind of like a
consumer and a merchant both being “known to VISA” to pay by credit card.<br></li><li>The
patient is in charge of their own data, and can update it — such as their phone
number — when necessary. The data should be in the well-known standard format
so that it can be consumed in a standard fashion.<br></li><li>The
authorization problems summary includes a starter set, such as emergency
scenarios. The patient might want to get very “discrete” (fine-grained) about
handing out data. Regulations are part of this landscape, including HIPAA and
other privacy/PII regs.<br></li><li>This
is going to be piloted this year by WEDI, so it’s not that futuristic. The use
case identifies benefits as well as challenges. The drivers for individuals are
convenience, managing our own data, and helping people in our care. Providers
also have strong drivers. Payers talk about how they have to generate insurance
ID cards, which has a cost.<br></li><li>Eve
suggests capturing the drivers/benefits as well as the challenges. Catherine is
involved in a startup, and has a good sense of the business drivers; she will
share those.<br></li><li>The
service is not a giant Rolodex in the sky that the payer or hospital queries to
get the individual’s information; the individual chooses to grant access to the
information. The individual might be onboarding to the provider’s system for
the first time, but this scenario could also suffice for a person returning and
updating information. “Registration” here includes not just provisioning a new
account, but also updating data in an existing record. Identity proofing and
authentication are not part of the process — thinking of someone who shows up
at a hospital, they’ll create a record if necessary no matter who you are!<br></li><li>There’s
the concept of “known to the practice”. This is a way to automate becoming
“known to the practice”. Attaching an existing record to a verifiable identity
supplied by an identity provider is not part of this use case. However, we note
that there’s a lot of medical identity theft, where a person poses as another
person and seeks care as that other person. “Record overlays” cause pernicious
problems around clinical risk.<br></li></ul><p></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"><b>VA
Secure RESTful Use Case - (</b> <a href="http://hg.openid.net/heart/wiki/VA_Secure_RESTful_Use_case">http://hg.openid.net/heart/wiki/VA_Secure_RESTful_Use_case</a><b> )</b></p>
<p class="MsoNormal"></p><ul><li>Justin
picked up on his use case.<br></li><li>There
was an IdP in each domain, there was OpenID Connect used as a login method to
an OAuth server in each case, there was a FHIR web client in each case, and
they were OAuth clients with tightly coupled OAuth authorization servers. (Some
of this was “demo-genic” to make things work smoothly.) Dynamic client
registration wasn’t used all over the place initially. Steve’s doctor, to view
Steve’s record at the ER, would require some sort of claims-based access a la
UMA. So the question is: What is the method? This wasn’t profiled yet. The
identity binding ceremony gets into legal requirements more than technology,
and wasn’t profiled; it’s unexciting on a technical level.<br></li><li>They
made up simple FHIR scopes, and didn’t write up a formal profile for that yet.
They did publish their source, however. They hope that work will feed into this
group’s work.<br></li><li>The
intention of what we want to profile is to layer specs, so that our UMA profile
can layer on top of the OAuth profile. If anyone needs just the OAuth
functionality, then they can just use the underlying spec etc.<br></li><li>Profiling
and Stacks<br></li><li>What
does the “decision tree” look like for what technologies anyone would use in
securing/protecting/access controlling (etc.) a health data API? Specifically,
when would one use OAuth, OpenID Connect, UMA, which kinds of client
applications, etc.? Eve suspects it’s truly a “layer cake”.<br></li></ul><p></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"><br></p><p class="MsoNormal"><b>AI</b>:
Eve: Propose a decision tree for choosing the high-level "Venn" technologies
(and thus their corresponding HEART profiles) - approximately 2 weeks</p>
<p class="MsoNormal"><b>AI</b>:
Justin: Send excerpted contributed-profile information on choosing specific
kinds of client applications to the list. </p><p class="MsoNormal"></p><ul><li>[DONE - <a href="http://hg.openid.net/heart/wiki/VA_OAuth_references">http://hg.openid.net/heart/wiki/VA_OAuth_references</a> ]<br></li></ul><p></p><p class="MsoNormal"> </p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>Upcoming Meetings</b></p><p class="MsoNormal"></p><ul><li>March 2 - Adrian Gropper will present Post MI Implant and Rehab use case (in progress .. <a href="http://hg.openid.net/heart/wiki/Post-MI_Implant_and_Rehab">http://hg.openid.net/heart/wiki/Post-MI_Implant_and_Rehab</a>)<br></li><li>March 9 - Focus on Delegation <br></li></ul><div><b>General </b></div><div><ul><li><b>Public wiki : </b><a href="http://hg.openid.net/heart/wiki/Home" style="font-family:'Times New Roman',serif;font-size:12pt">http://hg.openid.net/heart/wiki/Home</a><br></li><li><b>Resources</b> (slides etc) : <a href="http://hg.openid.net/heart/wiki/Home" style="font-family:'Times New Roman',serif;font-size:12pt">http://openid.net/wg/heart/resources/</a><br></li></ul></div><div><br></div><div>A couple of the member requested a meeting invite for the weekly meetings - Note there is an iCal link on the home page <a href="http://openid.net/heart/">http://openid.net/heart/</a></div><div><br></div><div><br></div><p></p></div>