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

it's difficult to understand the intended content structure(s)

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US PACIO Advance Directive Interoperability (FHIR)
    • 0.1.0
    • Patient Empowerment
    • STU
    • (many)
    • Hide

      In accordance with FHIR-34832 (At the top of the General Guidance page):

      • In the General Guidance page (general_guidance.html) Change the section title "Profile & Resource relationships" to "Structure and Resource Relationships" and change the first paragraph:
        From:
        Advance directive documents may take several forms including scanned PDF documents, CDA documents and native FHIR documents. This guide defines interoperability to support any number of types, though focuses on native FHIR documents.

      To: 

      Advance directive documents may take several forms including scanned PDF documents, CDA documents, other binary documents, and native FHIR documents (using the Composition and other ADI-specific profiled FHIR resources). This guide defines interoperability to support all of these types and other potential document types (through encoding in a Binary resource). Today, most of these documents are shared through scanned images. This implementation guide is designed to allow a range of digitization levels, from scanned documents to fully discrete FHIR documents. Additionally, this guide provides the capability for different types of data to be more digitized than others inside the same document. 
       

      This section (already) continues to state:
      All documents, regardless of format is saved in the Binary resource and is available through the Binary endpoint. FHIR native documents SHALL be Bundle resources with type = document and encoded as a Binary resource. Documents that are communicated SHALL have at least one DocumentReference resource that references the Binary though the DocumentReference.content.attachment.url.

      Show
      In accordance with FHIR-34832 (At the top of the General Guidance page): In the General Guidance page (general_guidance.html) Change the section title "Profile & Resource relationships" to "Structure and Resource Relationships" and change the first paragraph: From: Advance directive documents may take several forms including scanned PDF documents, CDA documents and native FHIR documents. This guide defines interoperability to support any number of types, though focuses on native FHIR documents. To:  Advance directive documents may take several forms including scanned PDF documents, CDA documents, other binary documents, and native FHIR documents (using the Composition and other ADI-specific profiled FHIR resources). This guide defines interoperability to support all of these types and other potential document types (through encoding in a Binary resource). Today, most of these documents are shared through scanned images. This implementation guide is designed to allow a range of digitization levels, from scanned documents to fully discrete FHIR documents. Additionally, this guide provides the capability for different types of data to be more digitized than others inside the same document.    This section (already) continues to state: All documents, regardless of format is saved in the Binary resource and is available through the Binary endpoint. FHIR native documents  SHALL  be Bundle resources with  type  =  document  and encoded as a Binary resource. Documents that are communicated  SHALL  have at least one DocumentReference resource that references the Binary though the  DocumentReference.content.attachment.url .
    • Corey Spears / Abigail Watson : 13 - 0 - 0
    • Clarification
    • Non-substantive

    Description

      It's difficult to understand the intended exchange patterns

       

      After spending a few hours with this IG, my understanding of how these ADI resources are assembled together is still fuzzy. It would be immensely hepful, if you would add something like the below at the top of the formal spec, or even a more prevalent location:

       

      This specification defines the exchange of ADI content in the form of scanned documents as well as other binary documents, or as a discrete FHIR document using Composition and other ADI-specific profiled FHIR resources. In all cases, the ADI content is contained within a single a single Binary resource and a compliant FHIR server supports create, update and read interactions on the Binary resource.

       

       

      Is the above correct? If not, you should take it as further proof that such a technical overview is necsesary.

      Attachments

        Activity

          People

            bmeshell Brian Meshell
            Isaac.Vetter Isaac Vetter
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: