<div dir="ltr">First - i fundamentally agree with Justin's request that HEART needs to find a purpose that aligns with the needs of the market - His assertion was more of the type that HEART got no tracktion the last time around.<div>There are two way to approach this:</div><div>1. find a business purpose</div><div>2. find a set of appropriate use cases with problems that need to be solved.</div><div>I would recommend #2 - lets build use cases based on needs.</div><div>I have started a potential list of use cases that could be a starting point.</div><div>I am strongly opposed to the current approach of looking at solutions (FAPI, UMA, whatever) before we understand what value we can contribute.</div><div><br></div><div>wrt Justin's proposal on TXAUTH to HEART - i note one missing element - specifically  how does the requesting site tell the sending site what data they want in a manner that permits the user to accept or request the request. I do not believe that a list of FHIR data elements is something that the user could evaluate. If we want to put the user in control, we must provide the user a choice that they can understand. I can share the Kantara doc on patient choice if that is desired. TXAuth does not currently do that, but could be adapted to do it.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div></div></div>