The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges. This profile includes both Consent profiling and access controls profiling of oAuth access token.
R4B was used as R4B includes a technical correction in Consent resource that fixes a profiling error. However, it is clear now that R4B is not the version of FHIR that is being published (evidence gathered on the DSUB for Mobile).
R4B does have significant changes in for example the medications, clinical reasoning, and subscriptions; but R4B was also intended to be the technical-correction minor correction on R4 for fixes like that done for Consent. Unfortunately, because of the significant changes, the R4B release can't be seen purely as a minor technical-correction release of R4.
The current release does include statements that it is compatible with R4 and does have both R4 and R4B packages. However, the experience we have with DSUB for Mobile shows that one can't depend on an R4B IG and further refine (profile) the source profiles. Thus, keeping PCF at R4B will limit the kind of refinements.
Should the PCF be republished as an R4?
Should we do like the Subscription backport and create two different publications?
Building PCF as R4 will produce errors on each example
if identifier.system is 'urn:ietf:rfc:3986', then the identifier.value must be a full URI (e.g. start with a scheme), not 'Local eCMS identifier'
This does not affect the profile, and doesn't really affect the example. It would however need to be explained to our reader that it is understood and okay.
Building PCF as R4 also requires narrative references to R4B to be changed to R4.
R4B was used as R4B includes a technical correction in Consent resource that fixes a profiling error. However, it is clear now that R4B is not the version of FHIR that is being published (evidence gathered on the DSUB for Mobile).
R4B does have significant changes in for example the medications, clinical reasoning, and subscriptions; but R4B was also intended to be the technical-correction minor correction on R4 for fixes like that done for Consent. Unfortunately, because of the significant changes, the R4B release can't be seen purely as a minor technical-correction release of R4.
The current release does include statements that it is compatible with R4 and does have both R4 and R4B packages. However, the experience we have with DSUB for Mobile shows that one can't depend on an R4B IG and further refine (profile) the source profiles. Thus, keeping PCF at R4B will limit the kind of refinements.
Should the PCF be republished as an R4? Should we do like the Subscription backport and create two different publications?
Building PCF as R4 will produce errors on each example
This does not affect the profile, and doesn't really affect the example. It would however need to be explained to our reader that it is understood and okay.
Building PCF as R4 also requires narrative references to R4B to be changed to R4.