<div dir="ltr">The GDoc I shared on today's call is <a href="https://docs.google.com/document/d/1JtESkMgZ5FxEM74Ae4OE8MHj0wjAqDY7FpA52XJQtZw/edit?usp=sharing">here</a> (read-only link; send me a request if you need deeper access).<div><br></div><div>For those interested in an ad hoc session this week, I can meet at 1pm or 2pm ET on Wednesday, or 1pm ET on Thursday.</div><div><br></div><div>Key <i>use case</i> issues: Please see the table in the doc!</div><div><br></div><div>Key <i>technical/spec</i> issues for discussion:<div><br></div><div><b>Set list of scopes vs. flexibility</b></div><div>Require all resource servers to include the same list of scopes, or allow them flexibility? Considerations: interoperability, patient empowerment, RS capabilities...</div><div><br></div><div><b>The * scope idea</b></div><div>Should the profile dictate the availability of an "all" scope that stands for all of the possible scopes? Considerations: Standardizing it vs. letting individual RS's offer it if they want to, semantics of choosing this scope while also choosing other scopes, growth of future UMA best practices...</div><div><br></div><div><b>Legitimacy of RS scopes outside HEART choices</b></div><div>Okay to let RS's add other non-HEART scopes? If so, are there any constraints on what those scopes can be? Considerations: interoperability, patient empowerment...</div><div><br></div><div><b>Mixed FHIR/non-FHIR servers</b></div><div>Is the current way of handling mixed servers a good one, where any one registered resource set that is tied to a FHIR resource type has to be served in a FHIR-conforming way? Do we need to be more specific about meaning "read" scope"? Should we way something about requiring HEART clients to "write" FHIR resource data in a conforming way as well? Considerations: interoperability...</div><div><br></div><div><b>New issue: Hybrid FHIR/non-FHIR resources</b></div><div>Is it possible to have such a thing as a hybrid or extended FHIR resource? If so, how would or could such a thing be handled? Considerations: interoperability...</div><div><br></div><div><b>Cardinality of how many RS's can register a resource of the same FHIR type (or HEART bundle type) for the same patient, and what a client does with this situation</b></div><div>Need to say something about this? This depends on use cases/API calls. See the discussion in the doc.</div><div><br></div><div><b>New issue: Cardinality of how many resources of the same FHIR type (or HEART bundle type) the same RS can register for the same patient, and what a client does with this situation</b></div><div>Need to say something about this? This depends on use cases/API calls.</div><div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl</p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></div>