[Openid-specs-ab] Spec Call Notes 12-Aug-24
Tom Jones
thomasclinganjones at gmail.com
Tue Aug 13 04:35:24 UTC 2024
There is more than one trust framework associated with HealthCare in the US.
The QHIN - qualified Health Information went live over a year ago - see
below.
The other issue was requiring POST for OIDC. The Blue Button API (Medicare
- CMS) does NOT support POST but is otherwise OIDC.
==============
The Blue Button API does not support POST, please use GET instead. You can
see our swagger documentation here:
https://sandbox.bluebutton.cms.gov/docs/openapi
If you have a specific use case for POST requests, feel free to email us at
bluebuttonapi@ cms.hhs.gov and we may be able to point you in the right
direction.
==================
Trusted Exchange Framework and Common Agreement for Health Information
Networks Now Available
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 Trusted Exchange Framework and the Common
Agreement (TEFCA)
<https://pardot.sequoiaproject.org/e/405472/tefca-and-rce-resources-/7ts4kk/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>.
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.
The Common Agreement
<https://pardot.sequoiaproject.org/e/405472/Interoperability-Version-1-pdf/7ts4km/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>
includes
Standard Operating Procedures (SOPs) and the QHIN Technical Framework (QTF)
<https://pardot.sequoiaproject.org/e/405472/t-uploads-2022-01-QTF-0122-pdf/7ts4kp/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>.
Also available today is the Health Level Seven (HL7®) Fast Healthcare
Interoperability Resource (FHIR®) Roadmap for TEFCA Exchange
<https://pardot.sequoiaproject.org/e/405472/-FHIR-Roadmap-v1-0-updated-pdf/7ts4kr/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>,
which outlines how TEFCA will accelerate the adoption of FHIR-based
exchange across the industry.
The RCE will be hosting a series of public engagement webinars
<https://pardot.sequoiaproject.org/e/405472/community-engagement-/7ts4kt/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>
to
provide further information about TEFCA (the first of which will be on *January
26 at 1:00 PM ET*), in addition to our monthly informational *call today at
Noon
<https://pardot.sequoiaproject.org/e/405472/register-6651063890160530956/7ts4kw/982167152?h=KYWcLLEVCJhHwlC3v5JU14C8mXjEV0dZeujGUGO8NvI>
featuring
National Coordinator for Health IT Micky Tripathi*. 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.
..tom
On Mon, Aug 12, 2024 at 6:35 PM Michael Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Spec Call Notes 12-Aug-24
>
>
>
> Mike Jones
>
> Brian Campbell
>
> Nat Sakimura
>
> Alan Wang
>
> Dima Postnikov
>
> Victor Yu
>
> Bjorn Hjelm
>
> Tom Jones
>
> Edmund Jay
>
>
>
> Shared Signals Implementer's Drafts Vote
>
> Participate at
> https://openid.net/foundation/members/polls/334
>
>
>
> EU Implementing Acts
>
> There's a public comment period on the EU Implementing Acts
>
> Nat said that there are 5 documents
>
>
> https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives_en?text=European%20Digital%20Identity%20Wallets
>
> The feedback period is August 12 to
> September 9, 2024
>
> Nat said that the implementing acts specify ISO 18013-5 as
> the protocol
>
> We discussed that only final specifications can be
> referenced from implementing acts
>
> So the OpenID4VC specs, SD-JWT, etc. are
> not referenced
>
> Nat said that many things are still unspecified
>
> Such as rules for attributed attestations
>
> Nat remarked that there's a protocol for credential
> deletion
>
>
>
> [Openid-specs-ab] Call for Working Group Adoption of OpenID Federation
> Extended Subordinate Listing 1.0
>
> This spec defines how to do paginated listings of
> subordinates
>
> All respondents so far support adoption
>
>
>
> [Openid-specs-ab] Call for Working Group Adoption of OpenID Federation
> Wallet Architectures 1.0
>
> There's been some discussion of the contribution and
> whether it should be adopted as-is
>
> Joseph thought that some metadata values currently defined
> there should be in other specs
>
> In the long term, everyone responding to
> him agreed with him
>
> There was disagreement on whether adoption
> should wait for these values to be first defined elsewhere
>
> These were written down now to enable interoperable
> implementations of wallet ecosystems using Federation to be developed
>
> Mike asked Nat to be ready to make the adoption decision
> as chair next week
>
> Since John and Mike are authors
>
> Giuseppe sent a detailed message describing each of the
> defined metadata parameters and their purpose
>
> 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
>
> Nat agreed that we could make
> non-normative updates such as adding this note
>
> Bjorn said that he isn't dismissing
> Joseph's concerns
>
> Bjorn said that he also wants to be
> sensitive to people wanting to make progress and implement now
>
>
>
> Metadata parameter value arrays for RP metadata
>
>
> https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp
>
> Having PRs declare all their supported parameter values is
> useful in contexts where the RP isn't the one making the decision
>
> Mike is working on a small spec enabling this
>
> Nat thought it's a reasonable thing to do
>
> The Federation editors agreed with Stefan Santesson that
> this should be independent of the Federation spec
>
>
>
> Do we want to be able to retrieve Entity Configurations with the Fetch
> Endpoint?
>
> https://github.com/openid/federation/issues/30
>
> Mike asked whether people have code that retrieves an
> Entity Configuration via the Fetch Endpoint
>
> Rather than .well-known/openid-federation
>
> The Fetch Endpoint is used to retrieve Subordinate
> Statements
>
> An implementer pointed out that each API
> should do one thing
>
> In this case, being about
> retrieving Subordinate Statements
>
> Rather than also being
> used to retrieve Entity Configurations
>
> Mike asked if people had code using Fetch to retrieve
> Entity Configurations
>
> Dima doesn't use it for that
>
> Mike said that the editors were leaning towards making
> Fetch only for Subordinate Statements
>
> Dima welcomes the simplification
>
> Mike put the question to the list after the last call
>
> [Openid-specs-ab] Making the Fetch
> Endpoint specific to retrieving Subordinate Statements
>
>
>
> Carin Alliance
>
> Mike said that he'd been reached out to by the Carin
> Alliance about trust establishment with Federation
>
> https://www.carinalliance.com/
>
> They work on US healthcare standards
>
> They use the Unified Data Access Profiles
> https://www.udap.org/
>
> Tom reported that the Smart Health app uses OpenID Connect
>
> Tom mentioned Blue Button
> https://bluebutton.cms.gov/developers/
>
> He said that Blue Button can be used in
> Medicare to determine payment information
>
> He said that there's problem with POST in
> Blue Button, which it doesn't allow
>
> Tom described the Qualified Health Information Network
>
> Tom said that they could use Federation
>
> Tom also described PEFCA
>
> Tom suggested asking Carin what the nodes are
>
> Hospitals, Health Information Network, etc.
>
> Mike is speaking with them this week
>
>
>
> Next Call
>
> The next call is Monday, August 19th at 4pm US Pacific Time
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240812/6bb67c4a/attachment-0001.html>
More information about the Openid-specs-ab
mailing list