You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: