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

Constituent Resources as stand alone entities

    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
    • PADI CapabilityStatement [deprecated]
    • Formal Specification
    • 5.5, 7.1
    • Hide

      item 1. After discussion with reporter and review of the structure for HCA with the Consent resource, it was determined that the specification is currently sufficient and does not need to be modified to address the concern.

      Item 2.

      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.

      • 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. 

      Add guidance in ADIDocumentReference on how to handle scanned binary images.  Format codes for each type is different.  Use format codes specified by CDA to reference CDA documents.  Create new ticket.

      • In the General Guidance page (general_guidance.html) Change the section title "Document Structure" to "FHIR Document Structure"
      • The definition of Must Support has been changed according to FHIR-35075.
      • Change the CapabilityStatement Expectations of the following resources:
        • Composition: From SHALL to MAY
        • RelatedPerson: From SHALL to MAY
        • Consent: From SHALL to MAY
        • Goal: From SHALL to MAY
        • List: From SHALL to MAY
        • Observation: From SHALL to MAY
        • Provenance: From SHALL to MAY
      • Use contained resources, which greatly simplifies the CapabilityStatement for industry implementation.

      Meets industry where it is right now.

      • Change the following element requirements
        • PADI-PreferenceCarePlan
          • Make CarePlan.text 0..1 MS
          • Make CarePlan.goal 0..*
      Show
      item 1. After discussion with reporter and review of the structure for HCA with the Consent resource, it was determined that the specification is currently sufficient and does not need to be modified to address the concern. Item 2. Change http://hl7.org/fhir/us/pacio-adi/2022Jan/formal_specification.html#advance-directive-native-fhir-document-structure-requirements   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 . 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.  Add guidance in ADIDocumentReference on how to handle scanned binary images.  Format codes for each type is different.  Use format codes specified by CDA to reference CDA documents.  Create new ticket. In the General Guidance page (general_guidance.html) Change the section title "Document Structure" to "FHIR Document Structure" The definition of Must Support has been changed according to FHIR-35075 . Change the CapabilityStatement Expectations of the following resources: Composition: From SHALL to MAY RelatedPerson: From SHALL to MAY Consent: From SHALL to MAY Goal: From SHALL to MAY List: From SHALL to MAY Observation: From SHALL to MAY Provenance: From SHALL to MAY Use contained resources, which greatly simplifies the CapabilityStatement for industry implementation. Meets industry where it is right now. Remove Must Support from the following elements: PADI-Header Composition.padi-effective-date-extension Composition.padi-dataEnterer-extension Composition.padi-informant-extension Composition.padi-informationRecipient-extension Composition.padi-participant-extension Composition.padi-performer-extension Composition.padi-authorization-extension Composition.padi-clause-extension Composition.encounter Composition.attester:legal_attester Composition.attester:notary_attester Composition.attester:witness_attester Composition.section. padi-clause-extension PADI-PACPComposition Compostion. section:healthcare_agent_appointment (and all child elements except text) Compostion. section: gpp_personal_care_experience  (and all child elements except text) Compostion. section: gpp_for_certain_health_condition  (and all child elements except text) Compostion. section: gpp_upon_death  (and all child elements except text) Compostion. section: additional_documentation (and all child elements except text) Compostion. section: witness_and_notary  (and all child elements except text) Compostion. section: administrative_information  (and all child elements except text) PADI-PreferenceCarePlan CarePlan.goal PADI-Goal Goal.category Goal.category.text Goal.target.measure Goal.target.detail [x] Goal.target.expressedBy Goal.note PADI-PersonalGoal No Change PADI-ParticipantConsent Consent.policy Consent.provision. padi-clause-extension Consent.provision.period Consent.provision.actor. padi-clause-extension Consent.provision.actor.action PADI-Participant RelatedPerson.relationship RelatedPerson. relationship:personal_and_legal_relationship_role PADI-CareExperiencePreference No Change for this ticket PADI-PersonalInterventionPreference No Change for this ticket PADI-PersonalPrioritiesOrganizer No Change for this ticket PADI-AutopsyObservation Observation.note PADI-OrganDonationObservation Observation.code.text Observation.note PADI-Provenance No Change for this ticket Change the following element requirements PADI-PreferenceCarePlan Make CarePlan.text 0..1 MS Make CarePlan.goal 0..*
    • Dave Hill / Virginia Lorenzi : 7-0-0
    • Correction
    • Non-compatible

    Description

      Section 5.5 indicates that "This guide requires the interoperability of Advance Directive Information through the use of wholly contained documents as part of its use case. While it is required that this data be made interoperable as a collection of Advance Directive Information in document Bundles, systems may decide to make use of the constituent resources as separate resources for additional uses and purposes, such as use in support of Clinical Decision Support."

      1) the way the composition is structured, it would be very difficult to detach standalone elements.  For example, healthcare agent is a section header within the composition, with the loinc code hardcoded into the section header.  using ADI Participant standalone provides no context that the participant IS the healthcare agent.    A previous version of this implementation guide I believe provided a healthcare agent resource that would be an appropriate standalone element.

      2)  The landscape may evolve such that certain resources in the composition become digitally feasible before others.  Consider an implementation guide that allows for gradual transition of digital elements/resources combined with a document reference,e.g., PDF.  Example:  Declaration of Healthcare agent - discrete resource + remainder of patient goals and preferences contained within a scanned PDF.   

      Attachments

        Activity

          People

            may_terry May Terry
            kherman Kimberly Herman
            David Hill, Kimberly Herman, Michael Brodsky (Inactive)
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: