Attendees:

Debbie Bucci

Dustin Gage

Edmund Jay

Greg K

Jim Kragh

Justin Richer

Rachel Houseman

Mark Russell

Sarah Squire

Thompson Boyd

Tom Sullivan

William Kinsley

Nat Sakimura

Adrian Gropper

The patient should be given a FHIR API endpoint whether they ask for it or not. They can choose to authorize various things to use the API, but they shouldn’t have to ask for it.

The opt-in/opt-out choice comes when Alice chooses whether or not to authorize a client.

Alice can move information between her PHR and PCP portal, or request that information be synced automatically as it is added. The details of how that two-way sync could be accomplished has yet to be fleshed out.

Alice’s authorization servers will have white lists, black lists, and gray lists, which will determine the policy by which the authorization server agrees to register a client. Trust frameworks can provide a default policy. Alice can express her own policy preferences at run-time.

Alice’s FHIR identifier within all systems would be a unique URI. Ideally, this would be discovered automatically, but Alice should be able to paste it in manually in the case where discovery fails.

Alice can choose whether to do a one-time import of her information at registration, or to authorize an ongoing sync that allows new information to be imported every time it is added. The information that is imported into a client may or may not be used to update existing information. The client can also give Alice the option to refresh the cache that is being used by the client.

Justin Richer Update:

lice wants to move information between her PHR and PCP in either direction, this just changes the roles that each party plays. The PHR can be a client of the PCP's protected resource, or the PCP can be a client of the PHR's protected resource, or both. It's important that the protocols we're working on be able to work in either or both directions like this.

Adrian Gropper Update

Sarah's description, with Justin's amendment, is exquisite in its clarity and will be very helpful in our design. There is something that I hope we can repphrase for further clarity. These have to do with Authorization Servers and the FHIR Identifier.

The system will have many resource servers, many clients, many IDPs, and many federations, but there's only one Alice. To keep all of these system components honest and substitutable, Alice has to be able to specify her own authorization server. Whether the system as a whole ends up with only a handful of authorization servers or, as many authorization servers as there are patients, is not something we need to bake into HEART. This person-centric perspective is essential to making HEART work across HIPAA and non-HIPAA, wearables, IoT, clinical, and research applications. Each of these service providers will have their own policies and practices in and out of healthcare. They may or may not choose to participate in the same federations. But there will still be only one Alice.