Profile audience and scope

[ghost]

Revised wording to clarify scope to include processes to registration/pre-authorization backend service, and for runtime acquisition of access token. Explicitly stated that profile's applicability is not restricted to retrieval of bulk data. Clarified conditions under which profile applies.

[jmandel]

Wait, did you mean to close the entire PR?

[ghost]

No. Trying to recall how GitHub works when a lot of discussion is involved. I may need a refresher - or at least patience. 😕

• Dixie

Dixie Baker Office: 310-791-9671 Cell: 310-279-2579

On Oct 29, 2018, at 6:58 PM, Josh Mandel notifications@github.com<mailto:notifications@github.com> wrote:

Wait, did you mean to close the entire PR?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/smart-on-fhir/fhir-bulk-data-docs/pull/86#issuecomment-434144118, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKQxHWhagNf2A5aVsy1Dg1zt8-F-KQXaks5up7JYgaJpZM4X5GdB.

[jmandel]

I think we can help with both :-) to start, I'll hit the "reopen" button.

[isaacvetter]

Hey Guys,

It looks like this PR is introducing a couple of sentences that really strongly suggest that backend services and bulk data only work with an EHR as the server; yet, our existing use-case descriptions clearly support other scenarios.

Is it reasonable to not suggest that an EHR is always the bulk data server?

Isaac

Examples:

his profile is intended to be used by developers of back-end services that autonomously (or semi-autonomously) need to access FHIR resources from an EHR 

 The target EHR can register the backend service and pre-authorize access to a 

From this diff

[michelemottini]

It's what also the SMART specs use. It is not exact, but not sure what would be a good alternative

[jmandel]

In the intro scope paragraph @isaacvetter I'd propose adding something like:

(This specification uses the term "EHR" to refer to any data system that hosts FHIR data in the role of a bulk data server; it could include clinical data systems, financial data systems, and other health information systems.)

Does this work for you?

[ghost]

@jmandel @isaacvetter The problem I see with the proposed clarification is that we have defined the scope of this specification as specifically NOT being limited to bulk-data accesses, but rather in terms of the client having been pre-authorized to access the requested FHIR data. I recommend replacing the term "EHR" with "FHIR server" throughout (or FHIR resource server, FHIR authorization server where that more specificity is needed). Alternatively, we could use Josh's suggested wording and just drop "in the role of a bulk data server." My preference would be the former.

[jmandel]

Indeed --- if nothing else I should have written "in the role of a FHIR server". I would also be happy replacing the terms throughout though, as @bakerdb suggests.

[jmandel]

Quick follow-up on this one @bakerdb -- do you still want to apply the change from "EHR" to "FHIR Server" in this PR? (I'm happy to take care of the mechanics, or you can; just let me know.)

[ghost]

I'm in the process of changing both "backend server" to "client" (another conversation) and "EHR" to "FHIR server." I'll make these changes in both merged content and open pull requests, as appropriate, to minimize confusion.

[ghost]

I have completed going through both specifications (merged content and open PRs) to make sure the "client" and "FHIR server" language is used consistently.