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

Questions raised by this ballot

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Highest Highest
    • CodeX™ Radiation Therapy (FHIR)
    • 1.0.0-ballot [deprecated]
    • Cross-Group Projects
    • Table of Contents
    • Hide

      1) Security Architecture:  There is no inherent security architecture in FHIR or this IG, but standards such as OAuth can be combined with RESTful exchange of FHIR resources. This easy combination with modern security concepts is in fact one of the advantages of working with FHIR. Requirements for security architectures are not in scope of this IG. The IHE-RO Supplement (XRTS) for this use case “eXchange of RT Summaries”, which is based on this IG, requires that SMART on FHIR backend service authentication is supported.

      2) For radiotherapy treatment summary, the expectation is that FHIR can fully replace HL7 v2 messages. There are usages of HL7 v2 messages for this radiotherapy use case with similar contents, but but in a proprietary format, for example using ORU messages with Z segments. In IHE-RO, the XRTS Supplement was just voted to Public Comment for this use case, using the FHIR RESTful API along the CodeX RT Implementation Guide.

      3) FHIR supports string lengths that are unlikely to be a limitation in practice. For example, identifier or name strings can be 1024*1024 characters long. It is rather a challenge for implementations to properly develop and test for these potentially very long strings. It this IG we currently expect that this is still better than artificially limiting strings to shorter UI friendly sizes. Further feedback from Trial Use or other projects is very welcome.

      Show
      1) Security Architecture:  There is no inherent security architecture in FHIR or this IG, but standards such as OAuth can be combined with RESTful exchange of FHIR resources. This easy combination with modern security concepts is in fact one of the advantages of working with FHIR. Requirements for security architectures are not in scope of this IG. The IHE-RO Supplement (XRTS) for this use case “eXchange of RT Summaries”, which is based on this IG, requires that SMART on FHIR backend service authentication is supported. 2) For radiotherapy treatment summary, the expectation is that FHIR can fully replace HL7 v2 messages. There are usages of HL7 v2 messages for this radiotherapy use case with similar contents, but but in a proprietary format, for example using ORU messages with Z segments. In IHE-RO, the XRTS Supplement was just voted to Public Comment for this use case, using the FHIR RESTful API along the CodeX RT Implementation Guide. 3) FHIR supports string lengths that are unlikely to be a limitation in practice. For example, identifier or name strings can be 1024*1024 characters long. It is rather a challenge for implementations to properly develop and test for these potentially very long strings. It this IG we currently expect that this is still better than artificially limiting strings to shorter UI friendly sizes. Further feedback from Trial Use or other projects is very welcome.
    • Saul Kravitz/Juliet Rubini: 17-0-5

    Description

      Questions raised by our reviewer, Kevin Geminiuc:
      I have a few question on the radiology oncology ballot.
      1) Is there an inherited security architecture for the "messaging" and FHIR repository? Perhaps adding links to existing specifications.
      2) Is there a fit for use for IHE messages vs FHIR? Or will they just coexist?
      3) Is the standard addressing character limitation flaws in the existing HL7v2 standard? i.e. FHIR Documents for reporting?

      Attachments

        Activity

          People

            Unassigned Unassigned
            Brian_Pech Brian Pech
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: