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

Incorrect/inadequate specification of the need for instances of each profile to declare conformance to an appropriate profile

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US CARIN Blue Button (FHIR)
    • 1.0.0
    • Financial Mgmt
    • (NA)
    • Hide

      To meta.profile (1..*) add a slice with required patterns equal to the canonical C4BB uri with cardinality of 1..1 for all resources and specify the profile name and business version "|version" e.g. "|1.2.3". Remove Must support from meta.profile for all profiles.

      Add the following guidance in form of a note for all profiles:

      meta.profile is required as a matter of convenience of receiving systems. The meta.profile should be used by the Server to hint/assert/declare that this instance conforms to one (or more) stated profiles (with business versions). meta.profile does not capture any business logic, processing directives, or semantics (for example, inpatient or outpatient). Clients should not assume that the Server will exhaustively indicate all profiles with all versions that this instance conforms to. Clients can (and should) perform their own validation of conformance to the indicated profile(s) and to any other profiles of interest.

      Show
      To meta.profile (1..*) add a slice with required patterns equal to the canonical C4BB uri with cardinality of 1..1 for all resources and specify the profile name and business version "|version" e.g. "|1.2.3". Remove Must support from meta.profile for all profiles. Add the following guidance in form of a note for all profiles: meta.profile  is required as a matter of convenience of receiving systems. The meta.profile should be used by the Server to hint/assert/declare that this instance   conforms to one (or more) stated profiles (with business versions).  meta.profile  does not capture any business logic, processing directives, or semantics (for example, inpatient or outpatient). Clients should not assume that the Server will exhaustively indicate all profiles with all versions that this instance conforms to. Clients can (and should) perform their own validation of conformance to the indicated profile(s) and to any other profiles of interest.
    • Mark Roberts/Pat Taylor: 6-0-2
    • Enhancement
    • Compatible, substantive
    • 1.1.0

    Description

      From Zulip chat:  https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/Explanation.20Of.20Benefit.20meta.2Eprofile 

      There is an inadequate specification of the need for instances of each profile to declare conformance to an appropriate profile.   The current spec just requires that they declare conformance to SOME profile.    An example is inpatient institutional

      Name Flags Card. Type Description & Constraintsdoco
      .. ExplanationOfBenefit I 0..* C4BBExplanationOfBenefit Explanation of Benefit resource
      ... meta SΣ 1..1 Meta Metadata about the resource
      .... profile SΣ 1..* canonical(StructureDefinition) Profiles this resource claims to conform to

      What it doesn't say is what the value shall be.  I can look at an example, BUT I don't think coding to an example (which may not be correct) is the correct thing to do.  Is that the value that conformance requires? If so where is it stated in the IG (non-example)

      Solution:  Define parameterized Rulesets:

      insert RequireProfile(Canonical(profilename))

      that results in, for example

      • insert Metaprofile-supportedProfile-slice
      • profile[supportedProfile] = Canonical(C4BBOrganization)

      Attachments

        Activity

          People

            Unassigned Unassigned
            taylorpatriciab Patricia Taylor
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: