<div dir="ltr">In an ad hoc call today, Nancy, Justin, and I came up with proposed answers to these questions and also to the question of guidance on when to register resources. The GDoc (including its comments) shows the results. Brief answers are also below.<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="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>
<br><div class="gmail_quote">On Mon, Dec 19, 2016 at 2:17 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The GDoc I shared on today's call is <a href="https://docs.google.com/document/d/1JtESkMgZ5FxEM74Ae4OE8MHj0wjAqDY7FpA52XJQtZw/edit?usp=sharing" target="_blank">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></blockquote><div><br></div><div>See doc comment. For any FHIR resource type, supply that URI in the "type" property. Still to be answered: Whether we want to impose any constraints on targeted types, or profile how to use any types (e.g. Bundle, specifics of Observation, etc.). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>See doc wording. Flexibility allowed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>See doc comment. * not added.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>See doc comment. Non-HEART scopes implicitly legitimate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>See doc comment. Excessively explicit text removed; "correspondence" between UMA resource sets and FHIR resource types sufficient.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div><div>Oops! We didn't actually talk about this explicitly. Discuss?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>No action on both of these; they're exclusively the province of the semantic API (FHIR), not this profile.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class="HOEnZb"><font color="#888888"><div><div><div class="m_8510166929227549075gmail_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 <a href="tel:(425)%20345-6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | 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></font></span></div></div>
</blockquote></div><br></div></div>