Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address PoU from sender and receiver #138

Open
jlamy opened this issue Mar 6, 2023 · 2 comments
Open

Address PoU from sender and receiver #138

jlamy opened this issue Mar 6, 2023 · 2 comments
Labels
CP-worthy Should create a CP to be linked to this issue

Comments

@jlamy
Copy link
Contributor

jlamy commented Mar 6, 2023

Is your feature request related to a problem? Please describe.
We currently have an extension on Organization and Endpoint to tag each with Purposes of Use. But we haven't said exactly what that means. Historically, exchanges like eHx and Carequality have seemed to use a PoU tag to mean "purposes which I will respond to", but there isn't data on whether clients are making use of this. And more recently, TEFCA has advanced the opposite use case, where an Organization will advertise PoUs in the directory meaning "purposes which I will send in requests". These values are used by the sending QHIN, which must enforce the declared constraints on outgoing requests.

When the TEFCA directory spec comes out, it may clarify to say an Org's PoUs are those it will request with, and an Endpoint's PoUs are those it will respond to.

Describe the solution you'd like
We could consider the possible TEFCA usage for mCSD. However, given that we have been favoring OrganizationAffiliation for details of electronic communication, it might make more sense to put the PoU extension on OrganizationAffiliations that have the code HIEInitiator instead of Organization, for outgoing PoUs.

Describe alternatives you've considered
None

Additional context
The HL7 US National Directory (current branch being worked on) is dealing with this as well, and is aware of mCSD profiling - in fact will be using some of it. But exactly where the dividing line is going to be is still TBD.

@lukeaduncan lukeaduncan added the CP-worthy Should create a CP to be linked to this issue label Apr 26, 2023
@JohnMoehrke
Copy link
Contributor

if there are multiple meanings, then there should be multiple extensions.

@slagesse-epic
Copy link
Member

2 use cases we should try and incorporate:

  1. As an information requestor (pull), what is the maximum set of purposes of use for which I might initiate a request?
  2. As an information responder (pull), what is the maximum set of purposes of use for which I might be willing to respond.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CP-worthy Should create a CP to be linked to this issue
Projects
None yet
Development

No branches or pull requests

4 participants