Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-40583

Change Direct Address to be part of .telecom rather than .endpoint in PractitionerRole

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • US Core (FHIR)
    • 6.0.0-ballot [deprecated]
    • Cross-Group Projects
    • US Core PractitionerRole Profile
    • Hide

      1) Regarding to commenter's proposal:  

      We therefore propose that rather than requiring using .endpoint for this information, an additional Contact Point System code of direct-project be added to .telecom.system for use in Practitioner and PractitionerRole.  An extension could then be used to provide the necessary payload information.

      This proposal is not persuasive because the existing US Core Direct email Extension already serves the same function as a "direct-project" code.  There is no need for additional payload information using the extension.

      2) We agree that PractitionerRole.telecom could also be used in addition to Endpoint to communicate a Direct Address.  However, whether an implementer uses PractitionerRole.telecom or Endpoint depends upon whether the business use case dictates that an implementer needs to:

      ... providing the details of the addressing of the system, purpose of use, protocols required/provided, and any other details required to communicate between the systems. (such as configuration parameters, require headers ...) The address value in the endpoint can only be used in the context of the provided details.

       

      We propose to Change the bullet in US Core PractitionerRole Profile Profile specific implementation guidance from:

       

      • The PractitionerRole.endpoint is where a Direct address may be represented.

      to 

      • Direct addresses are be represented in the `telecom` element using the US Core Direct email Extension or in a referenced Endpoint as a "direct-project" endpoint connection type.

       

      3) Regarding the commenter's proposal:

      we suggest a constraint should be added to CareTeam.member clarifying that Practitioner and PractitionerRole are not both must support resources and that supporting either one of the two will fulfill the requirement.

      We already document this constraint here. 

      • Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and include search parameters), but SHALL support _at least one of them.

      However, there is currently no way to create a must support constraint in the current tooling.  (choices for computable constraints are limited to "error" and "warning")

      Show
      1) Regarding to commenter's proposal:   We therefore propose that rather than requiring using .endpoint for this information, an additional Contact Point System code of direct-project be added to .telecom.system for use in Practitioner and PractitionerRole.  An extension could then be used to provide the necessary payload information. This proposal is not persuasive because the existing US Core Direct email Extension  already serves the same function as a "direct-project" code.  There is no need for additional payload information using the extension. 2) We agree that PractitionerRole.telecom could also be used in addition to Endpoint to communicate a Direct Address.  However, whether an implementer uses PractitionerRole.telecom or Endpoint depends upon whether the business use case dictates that an implementer needs to: ... providing the details of the addressing of the system, purpose of use, protocols required/provided, and any other details required to communicate between the systems. (such as configuration parameters, require headers ...) The address value in the endpoint can only be used in the context of the provided details.   We propose to Change the bullet in US Core PractitionerRole Profile Profile specific implementation guidance from:   The PractitionerRole.endpoint is where a  Direct address  may be represented. to  Direct address es are be represented in the `telecom` element using the US Core Direct email Extension or in a referenced Endpoint as a "direct-project" endpoint connection type.   3) Regarding the commenter's proposal: we suggest a constraint should be added to CareTeam.member clarifying that Practitioner and PractitionerRole are not both must support resources and that supporting either one of the two will fulfill the requirement. We already document this constraint here .  Although  both  US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and  include   search parameters), but  SHALL  support _at least  one of them. However, there is currently no way to create a must support constraint in the current tooling.  (choices for computable constraints are limited to "error" and "warning")
    • Eric Haas / Brett Marquard : 12-0-0
    • Clarification
    • Non-substantive
    • Yes

    Description

      We are seeking clarification regarding the requirement to support a Direct address using PractitionerRole.endpoint or whether supporting a Direct address through PractitionerRole.telecom would meet the requirement.

      We note that PractitionerRole.endpoint is listed as must support, however the following guidance from the implementation guide implies that there are other places where Direct address may be returned:

      ‘The PractitionerRole.endpoint is where a Direct address may be represented.’

       

      Additionally, constraint pd-1 indicates that either PractitionerRole.telecom or PratitionerRole.endpoint can provide relevant contact information.

      Id Grade Path Details Requirements
      pd-1 error PractitionerRole SHALL have contact information or a reference to an Endpoint
      : telecom or endpoint      		  

       

      Considering that in the Practitioner resource .telecom is the only available attribute to convey a Direct address and that PractitionerRole is mostly practitioner focused, not organization focused (that would be PractitionerRole.organization), it seems that using PractitionerRol.telecom would be more consistent.

       

      We realize that for certain Direct addresses the endpoint data type would provide more context, but for typical Direct addresses the .telecom data type is sufficient.

       

      We also realize that Direct addresses are a special type of address, not really an e-mail address, where having the ability to indicate that telecom.system is “direct-project” would be sufficient to support the necessary context to correctly interact with that Direct address.

       

      We therefore propose that rather than requiring using .endpoint for this information, an additional Contact Point System code of direct-project be added to .telecom.system for use in Practitioner and PractitionerRole. An extension could then be used to provide the necessary payload information.

      Short of adding a new code of direct-project, the existing ‘other’ code, followed by a payload extension would also provide the necessary information.

      Continuing to group this information in .telecom for both Practitioner and PractitionerRole would ensure consistency between the two resources.

       

      As we reviewed the use of Practitioner and PractitionerRole in this context, we suggest a constraint should be added to CareTeam.member clarifying that Practitioner and PractitionerRole are not both must support resources and that supporting either one of the two will fulfill the requirement.

      Attachments

        Activity

          People

            Unassigned Unassigned
            jj027509 Jessica Bright
            Andrew Fagan, Hans Buitendijk
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: