Profile governed API

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • FHIR Infrastructure
    • (many)
    • Hide

      The community isn't ready for this and has not been clamoring for it, and you could potentially do this yourself using extensions. Also StructureDefinition is now normative. While we acknowledge that this could potentially make SD more powerful, we feel at this point we should close this out unless compelling reasons are provided to reopen it.

      Show
      The community isn't ready for this and has not been clamoring for it, and you could potentially do this yourself using extensions. Also StructureDefinition is now normative. While we acknowledge that this could potentially make SD more powerful, we feel at this point we should close this out unless compelling reasons are provided to reopen it.
    • Mark Kramer/Ewout Kramer: 7-0-2
    • Enhancement

      This proposal is described here and is a composite of a set of change requests to follow (that will reference this as the header).

      Essentially, this proposal is to set a guideline for servers to use profiles to govern their APIs to enable profile governed security and application access. This proposal:

      Allows implementers to constrain both instances and elements within instances to a particular profile for both read and write.

      Therefore defines a standard way for servers to communicate to clients precisely what will be returned in a payload and what may be submitted as a write.

      Therefore defines a standard way for a client to request a particular profile in its interactions with a server (read and write).

      Use cases and details are here.

            Assignee:
            Unassigned
            Reporter:
            Chris Grenz
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: