<div dir="ltr"><div class="gmail-content" tabindex="0" style="color:rgb(0,0,0);font-size:medium"><div class="gmail-ac-container gmail-ac-adaptiveCard"><div class="gmail-ac-textBlock"><p>Certainly! <strong>Azure</strong> provides support for <strong>SMART on FHIR</strong>, which is a healthcare standard enabling applications to access clinical information through a data store. Here are the key points:</p><ol><li><p><strong>What Is SMART on FHIR?</strong></p><ul><li><strong>SMART on FHIR</strong> combines open standards like <strong>OAuth2</strong> and <strong>OpenID Connect</strong> with <strong>FHIR interfaces</strong>.</li><li>It allows applications to securely integrate with <strong>Electronic Health Record (EHR) systems</strong> and access clinical data.</li><li><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-tooltip-target" target="_blank">By adding a security layer, it ensures authentication and authorization for FHIR repositories</a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="1:"><sup class="gmail-citation-sup">1</sup></a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/azure-api-for-fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="2:"><sup class="gmail-citation-sup">2</sup></a>.</li></ul></li><li><p><strong>Benefits of Using SMART on FHIR</strong>:</p><ul><li><strong>Authentication and Authorization</strong>: Applications have a known method for obtaining authentication and authorization to a FHIR repository.</li><li><strong>Restricted Access</strong>: Users accessing a FHIR repository via SMART on FHIR are limited to resources associated with their user profile.</li><li><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-tooltip-target" target="_blank"><strong>Granular Data Access</strong>: Users can grant applications access to specific subsets of their data using SMART clinical scopes</a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="1: Granular Data Access"><sup class="gmail-citation-sup">1</sup></a>.</li></ul></li><li><p><strong>Setting Up SMART on FHIR with Azure</strong>:</p><ul><li><strong>Prerequisites</strong>:<ul><li>An instance of the <strong>FHIR Service .NET SDK 6.0</strong>.</li><li><strong>Cross-Origin Resource Sharing (CORS)</strong> enabled.</li><li>A registered <strong>public client application</strong> in <strong>Microsoft Entra ID</strong>.</li><li>Access to an <strong>Azure Subscription</strong> for creating resources and role assignments.</li></ul></li><li><strong>Steps</strong>:<ul><li>Set up the <strong>FHIR SMART user role</strong> to manage user access.</li><li><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-tooltip-target" target="_blank">Integrate the <strong>FHIR server</strong> with other Azure services using <strong>samples</strong> (such as APIM, Azure Functions, etc.)</a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="1: samples"><sup class="gmail-citation-sup">1</sup></a>.</li></ul></li></ul></li><li><p><strong>Note</strong>:</p><ul><li><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-tooltip-target" target="_blank">The <strong>open-source FHIR Server for Azure</strong> includes a simple <strong>SMART on FHIR app</strong></a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="1: SMART on FHIR app"><sup class="gmail-citation-sup">1</sup></a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/overview" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="3: SMART on FHIR app"><sup class="gmail-citation-sup">3</sup></a>.</li><li><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-tooltip-target" target="_blank">These samples are not part of the <strong>Azure Health Data Service</strong> and are not officially supported by Microsoft</a><a href="https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir" class="gmail-ac-anchor gmail-sup-target" target="_blank" aria-label="1: Azure Health Data Service"><sup class="gmail-citation-sup">1</sup></a>.</li></ul></li></ol><p>In summary, Azure supports SMART on FHIR, allowing secure integration of healthcare applications with FHIR data repositories.</p></div><div class="gmail-ac-horizontal-separator" aria-hidden="true"></div></div></div><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">FROM THE BING COPILOT!!!! </span>..tom</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 8, 2024 at 3:15 PM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</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 dir="ltr">i guess i should have noted that I was the one to connect FHIR devs, one of whom works for Microsoft.<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"> </span>..tom<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 8, 2024 at 3:11 PM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</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 dir="ltr">Mike - the reason to go to oidc 1.1 is that we expect RSA to be deprecated this year - and oidc requires it.<div><br clear="all"><div><div dir="ltr" class="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"> </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 8, 2024 at 7:47 AM Joseph Heenan 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><div><div dir="ltr">Attendees:</div><div dir="ltr"><br></div><div dir="ltr">Joseph Heenan</div><div dir="ltr">Michael Jones</div><div dir="ltr">George Fletcher</div><div dir="ltr">Bjorn Hjelm</div><div dir="ltr">Brian Campbell</div><div dir="ltr">David Waite</div><div dir="ltr">Filip Skokan</div><div dir="ltr">Pamela Dingle</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Only 3.5 weeks left to make submissions for IETF</div><div dir="ltr"><br></div><div dir="ltr"><u>Native SSO</u></div><div dir="ltr"><br></div><div dir="ltr"></div><div dir="ltr"><a href="https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction" target="_blank">https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction</a> - George to raise a PR<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><a href="https://lists.openid.net/pipermail/openid-specs-ab/2024-February/010226.html" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2024-February/010226.html</a> - George will respond on the list</div><div dir="ltr"><br></div><div dir="ltr"><u>Federation</u></div><div dir="ltr"><br></div><div dir="ltr"><a href="https://bitbucket.org/openid/connect/pull-requests/695" target="_blank">https://bitbucket.org/openid/connect/pull-requests/695</a> - Conflicts resolved, Mike plans to merge.</div><div dir="ltr"><br></div><div dir="ltr">Mike & others spoke with Stefan Santesson about the federation issues he had raised, which seemed to come down to potentially not trusting RPs to do key management. A productive discussion was had and Mike plans to close many of the issues.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><u>POST at authorization endpoint</u></div><div dir="ltr"><br></div><div dir="ltr">Joseph noted there was further discussion on <a href="https://gitlab.com/openid/conformance-suite/-/issues/1293" target="_blank">https://gitlab.com/openid/conformance-suite/-/issues/1293</a> that should be happening within the Connect working group instead.</div><div dir="ltr"><br></div><div dir="ltr">Mike asked Joseph to open an issue in the connect tracker, which Joseph did: <a href="https://bitbucket.org/openid/connect/issues/2115/post-to-authorization-endpoint" target="_blank">https://bitbucket.org/openid/connect/issues/2115/post-to-authorization-endpoint</a></div><div dir="ltr"><br></div><div dir="ltr">Brian noted that Ping does accept POST on the Authorization Endpoint.</div><div dir="ltr"><br></div><div dir="ltr">There was general discussion about adding conformance tests vs discouraging this is the spec, and noted that FHIR spec requires the authorization server support this as per Aaron’s original message, that if we were encourage people to implement POST it’d be better to push them towards PAR.</div><div dir="ltr"><br></div><div dir="ltr">An errata can’t make a normative change to the current requirement in OpenID Connect to support POST at Authorization Endpoint.</div><div dir="ltr"><br></div><div dir="ltr">Mike said a 1.1 for this would be overkill. Pam asked if there’s anything else that would go into 1.1. Filip suggesting returning access tokens from the Authorization Endpoint could also be removed. Mike said he wouldn’t want to start 1.1 while the ISO PAS submission was ongoing, which may take 9 months.</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">George suggested adding a conformance test that only issues a warning if it fails, and also creating a new conformance profile that requires it be supported as per FHIR.</div><div><br></div></div><div dir="ltr">Joseph asked if FHIR intend to use our certification tests. No one knew. Mike J suggested it would be worth discussing again on a call where Aaron was present. </div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><u>Moving to github</u></div><div dir="ltr"><br></div><div dir="ltr">Pam asked if everything is moving to GitHub. MikeJ said it’s been handled on a case by case basis, and e.g. the Federation authors would like to move to GitHub once they have some existing issues & PRs closed (as the PRs/issues do not transfer over well).</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"></div></div></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>
</blockquote></div>
</blockquote></div>
</blockquote></div>