Uploaded image for project: 'Other Specification Feedback'
  1. Other Specification Feedback
  2. OTHER-2774

Elminate support for excess FHIR paradigms

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • HL7/IHE Specification: Service-oriented Device Point-of-care Interoperability Technical Framework (OTHER)
    • 2024JAN
    • Devices
    • (N/A)
    • 1:10.1.1.5
    • Hide

      Update the indicated text to clarify that the ability of using multiple FHIR architectural paradigms, BUT that a specific gateway specification (e.g., in TF-2B) will constrain to specific paradigm(s).  To facilitate interoperability, named options may be added to specialized actors to clearly indicate what a given implementation supports.

      Consider speaking to the role of FHIR IGs as potentially further constraining FHIR ecosystem.

      Primary / priority paradigms are:  RESTful and messaging.

      Note:  In Cross Profile Considerations - include potential uses such as PDQm.  

      Show
      Update the indicated text to clarify that the ability of using multiple FHIR architectural paradigms, BUT that a specific gateway specification (e.g., in TF-2B) will constrain to specific paradigm(s).  To facilitate interoperability, named options may be added to specialized actors to clearly indicate what a given implementation supports. Consider speaking to the role of FHIR IGs as potentially further constraining FHIR ecosystem. Primary / priority paradigms are:  RESTful and messaging. Note:  In Cross Profile Considerations - include potential uses such as PDQm.  
    • John Rhoads / Javier Espina : 7-0-1
    • Clarification
    • Non-substantive

    Description

      Allowing REST, messaging, document, or SOA paradigms does not enhance interoperability. You could have two systems unable to communicate because one uses documents and the other REST. Please select a single preferred paradigm, or define named options that can be used to pair actor capabilities.

      Existing Wording:

      Gateways implementing this actor can support any of the FHIR architectural approaches: RESTful, messaging, documents, and SOA.

      (Comment 14 - imported by: Ron G. Parker)

      Attachments

        Activity

          People

            Unassigned Unassigned
            Rongparker Ron G. Parker
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: