<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">There is more than one trust framework associated with HealthCare in the US.</span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">The QHIN - qualified Health Information went live over a year ago - see below.</span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">The other issue was requiring POST for OIDC. The Blue Button API (Medicare - CMS) does NOT support POST but is otherwise OIDC.</span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"><br></span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">==============</span></div><div>The Blue Button API does not support POST, please use GET instead. You can see our swagger documentation here: <a href="https://sandbox.bluebutton.cms.gov/docs/openapi" target="_blank">https://sandbox.bluebutton.cms.gov/docs/openapi</a><div>If you have a specific use case for POST requests, feel free to email us at bluebuttonapi@ <a href="http://cms.hhs.gov/" target="_blank">cms.hhs.gov</a> and we may be able to point you in the right direction.</div></div><div>==================</div><div><div><div><div><div><div><div><div><div><p align="center" style="margin:0in;text-align:center;vertical-align:top;word-break:break-word"><span style="font-size:28.5pt;font-family:"Source Sans Pro",sans-serif;color:rgb(0,112,137)">Trusted Exchange Framework and Common Agreement for Health Information Networks Now Available<u></u><u></u></span></p><p align="center" style="margin:0in;text-align:center;vertical-align:top;word-break:break-word"><strong><span style="font-size:10.5pt;font-family:"Source Sans Pro",sans-serif;color:rgb(0,112,137)"> </span></strong><span style="font-size:10.5pt;font-family:"Source Sans Pro",sans-serif;color:rgb(0,112,137)"><u></u><u></u></span></p></div></div></div></div></div></div></div></div><div><div><div><div><div><div><div><div><p style="margin:0in;vertical-align:top"><span style="font-family:"Source Sans Pro",sans-serif;color:rgb(89,88,88)">The U.S. Department of Health and Human Services’ (HHS) Office of the National Coordinator for Health Information Technology (ONC) and its Recognized Coordinating Entity (RCE), The Sequoia Project, Inc., today announced the publication of the <a href="https://pardot.sequoiaproject.org/e/405472/tefca-and-rce-resources-/7ts4kk/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">Trusted Exchange Framework and the Common Agreement (TEFCA)</a>. Entities will soon be able to apply and be designated as Qualified Health Information Networks (QHINs). QHINs will connect to one another and enable their participants to engage in health information exchange across the country.<br><br>The <a href="https://pardot.sequoiaproject.org/e/405472/Interoperability-Version-1-pdf/7ts4km/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">Common Agreement</a> includes Standard Operating Procedures (SOPs) and the <a href="https://pardot.sequoiaproject.org/e/405472/t-uploads-2022-01-QTF-0122-pdf/7ts4kp/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">QHIN Technical Framework (QTF)</a>. Also available today is the Health Level Seven (HL7®) <a href="https://pardot.sequoiaproject.org/e/405472/-FHIR-Roadmap-v1-0-updated-pdf/7ts4kr/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">Fast Healthcare Interoperability Resource (FHIR®) Roadmap for TEFCA Exchange</a>, which outlines how TEFCA will accelerate the adoption of FHIR-based exchange across the industry.<br><br>The RCE will be hosting a <a href="https://pardot.sequoiaproject.org/e/405472/community-engagement-/7ts4kt/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">series of public engagement webinars</a> to provide further information about TEFCA (the first of which will be on <strong>January 26 at 1:00 PM ET</strong>), in addition to our monthly informational <strong><a href="https://pardot.sequoiaproject.org/e/405472/register-6651063890160530956/7ts4kw/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI" target="_blank">call today at Noon</a> featuring National Coordinator for Health IT Micky Tripathi</strong>. This will help entities interested in participating in or leveraging the benefits of TEFCA fully understand how it works and help prospective QHINs decide whether they should sign the Common Agreement. Following an application and review process, entities that have signed may be designated QHINs by the RCE. It is anticipated the initial QHINs will onboard to the network-of-networks to begin sharing data with one another this year.</span></p></div></div></div></div></div></div></div></div></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"> </span>..tom</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2024 at 6:35 PM Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div lang="EN-US">
<div>
<p class="MsoNormal">Spec Call Notes 12-Aug-24<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal">Brian Campbell<u></u><u></u></p>
<p class="MsoNormal">Nat Sakimura<u></u><u></u></p>
<p class="MsoNormal">Alan Wang<u></u><u></u></p>
<p class="MsoNormal">Dima Postnikov<u></u><u></u></p>
<p class="MsoNormal">Victor Yu<u></u><u></u></p>
<p class="MsoNormal">Bjorn Hjelm<u></u><u></u></p>
<p class="MsoNormal">Tom Jones<u></u><u></u></p>
<p class="MsoNormal">Edmund Jay<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Shared Signals Implementer's Drafts Vote<u></u><u></u></p>
<p class="MsoNormal"> Participate at <a href="https://openid.net/foundation/members/polls/334" target="_blank">
https://openid.net/foundation/members/polls/334</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">EU Implementing Acts<u></u><u></u></p>
<p class="MsoNormal"> There's a public comment period on the EU Implementing Acts<u></u><u></u></p>
<p class="MsoNormal"> Nat said that there are 5 documents<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives_en?text=European%20Digital%20Identity%20Wallets" target="_blank">
https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives_en?text=European%20Digital%20Identity%20Wallets</a><u></u><u></u></p>
<p class="MsoNormal"> The feedback period is August 12 to September 9, 2024<u></u><u></u></p>
<p class="MsoNormal"> Nat said that the implementing acts specify ISO 18013-5 as the protocol<u></u><u></u></p>
<p class="MsoNormal"> We discussed that only final specifications can be referenced from implementing acts<u></u><u></u></p>
<p class="MsoNormal"> So the OpenID4VC specs, SD-JWT, etc. are not referenced<u></u><u></u></p>
<p class="MsoNormal"> Nat said that many things are still unspecified<u></u><u></u></p>
<p class="MsoNormal"> Such as rules for attributed attestations<u></u><u></u></p>
<p class="MsoNormal"> Nat remarked that there's a protocol for credential deletion<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">[Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Extended Subordinate Listing 1.0<u></u><u></u></p>
<p class="MsoNormal"> This spec defines how to do paginated listings of subordinates<u></u><u></u></p>
<p class="MsoNormal"> All respondents so far support adoption<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">[Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Wallet Architectures 1.0<u></u><u></u></p>
<p class="MsoNormal"> There's been some discussion of the contribution and whether it should be adopted as-is<u></u><u></u></p>
<p class="MsoNormal"> Joseph thought that some metadata values currently defined there should be in other specs<u></u><u></u></p>
<p class="MsoNormal"> In the long term, everyone responding to him agreed with him<u></u><u></u></p>
<p class="MsoNormal"> There was disagreement on whether adoption should wait for these values to be first defined elsewhere<u></u><u></u></p>
<p class="MsoNormal"> These were written down now to enable interoperable implementations of wallet ecosystems using Federation to be developed<u></u><u></u></p>
<p class="MsoNormal"> Mike asked Nat to be ready to make the adoption decision as chair next week<u></u><u></u></p>
<p class="MsoNormal"> Since John and Mike are authors<u></u><u></u></p>
<p class="MsoNormal"> Giuseppe sent a detailed message describing each of the defined metadata parameters and their purpose<u></u><u></u></p>
<p class="MsoNormal"> Bjorn asked whether an editor's note could be added saying that the metadata parameters could eventually be defined elsewhere and then referenced there once that's been done<u></u><u></u></p>
<p class="MsoNormal"> Nat agreed that we could make non-normative updates such as adding this note<u></u><u></u></p>
<p class="MsoNormal"> Bjorn said that he isn't dismissing Joseph's concerns<u></u><u></u></p>
<p class="MsoNormal"> Bjorn said that he also wants to be sensitive to people wanting to make progress and implement now<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Metadata parameter value arrays for RP metadata<u></u><u></u></p>
<p class="MsoNormal"><a href="https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp" target="_blank">https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp</a><u></u><u></u></p>
<p class="MsoNormal"> Having PRs declare all their supported parameter values is useful in contexts where the RP isn't the one making the decision<u></u><u></u></p>
<p class="MsoNormal"> Mike is working on a small spec enabling this<u></u><u></u></p>
<p class="MsoNormal"> Nat thought it's a reasonable thing to do<u></u><u></u></p>
<p class="MsoNormal"> The Federation editors agreed with Stefan Santesson that this should be independent of the Federation spec<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Do we want to be able to retrieve Entity Configurations with the Fetch Endpoint?<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://github.com/openid/federation/issues/30" target="_blank">
https://github.com/openid/federation/issues/30</a><u></u><u></u></p>
<p class="MsoNormal"> Mike asked whether people have code that retrieves an Entity Configuration via the Fetch Endpoint<u></u><u></u></p>
<p class="MsoNormal"> Rather than .well-known/openid-federation<u></u><u></u></p>
<p class="MsoNormal"> The Fetch Endpoint is used to retrieve Subordinate Statements<u></u><u></u></p>
<p class="MsoNormal"> An implementer pointed out that each API should do one thing<u></u><u></u></p>
<p class="MsoNormal"> In this case, being about retrieving Subordinate Statements<u></u><u></u></p>
<p class="MsoNormal"> Rather than also being used to retrieve Entity Configurations<u></u><u></u></p>
<p class="MsoNormal"> Mike asked if people had code using Fetch to retrieve Entity Configurations<u></u><u></u></p>
<p class="MsoNormal"> Dima doesn't use it for that<u></u><u></u></p>
<p class="MsoNormal"> Mike said that the editors were leaning towards making Fetch only for Subordinate Statements<u></u><u></u></p>
<p class="MsoNormal"> Dima welcomes the simplification<u></u><u></u></p>
<p class="MsoNormal"> Mike put the question to the list after the last call<u></u><u></u></p>
<p class="MsoNormal"> [Openid-specs-ab] Making the Fetch Endpoint specific to retrieving Subordinate Statements<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Carin Alliance<u></u><u></u></p>
<p class="MsoNormal"> Mike said that he'd been reached out to by the Carin Alliance about trust establishment with Federation<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://www.carinalliance.com/" target="_blank">https://www.carinalliance.com/</a><u></u><u></u></p>
<p class="MsoNormal"> They work on US healthcare standards<u></u><u></u></p>
<p class="MsoNormal"> They use the Unified Data Access Profiles <a href="https://www.udap.org/" target="_blank">
https://www.udap.org/</a><u></u><u></u></p>
<p class="MsoNormal"> Tom reported that the Smart Health app uses OpenID Connect<u></u><u></u></p>
<p class="MsoNormal"> Tom mentioned Blue Button <a href="https://bluebutton.cms.gov/developers/" target="_blank">
https://bluebutton.cms.gov/developers/</a><u></u><u></u></p>
<p class="MsoNormal"> He said that Blue Button can be used in Medicare to determine payment information<u></u><u></u></p>
<p class="MsoNormal"> He said that there's problem with POST in Blue Button, which it doesn't allow<u></u><u></u></p>
<p class="MsoNormal"> Tom described the Qualified Health Information Network<u></u><u></u></p>
<p class="MsoNormal"> Tom said that they could use Federation<u></u><u></u></p>
<p class="MsoNormal"> Tom also described PEFCA<u></u><u></u></p>
<p class="MsoNormal"> Tom suggested asking Carin what the nodes are<u></u><u></u></p>
<p class="MsoNormal"> Hospitals, Health Information Network, etc.<u></u><u></u></p>
<p class="MsoNormal"> Mike is speaking with them this week<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Next Call<u></u><u></u></p>
<p class="MsoNormal"> The next call is Monday, August 19th at 4pm US Pacific Time<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></blockquote></div>