Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define mustSupport for CH-Core (Oliver Egger, ahdis) #99

Closed
ig-feedback opened this issue Mar 15, 2021 · 5 comments
Closed

Define mustSupport for CH-Core (Oliver Egger, ahdis) #99

ig-feedback opened this issue Mar 15, 2021 · 5 comments

Comments

@ig-feedback
Copy link
Collaborator

ch.fhir.ig.ch-core#1.2.0 /

mustSupport behaviour is not defined for this implementation guide, this should be defined

Oliver Egger, ahdis

@ziegm ziegm added the STU 1.2.0 Ballot Comments/Issues from the Ballot for STU2 label Mar 17, 2021
@oliveregger oliveregger removed the STU 1.2.0 Ballot Comments/Issues from the Ballot for STU2 label Apr 4, 2021
@ziegm
Copy link
Collaborator

ziegm commented Oct 26, 2021

  • CH ORF (no description)
  • CH LAB-Order (no description)
  • CH RAD-Order (no description)
  • CH eTOC (no description)
  • CH AllergyIntolerance, see description
    • The Must Support flags have been set as in AllergyIntolerance IPS plus reaction.substance which has its own value set for substances, whereas the value set for AllergyIntolerance.code is based on the corresponding findings, which can be used also to document conditions with relation to allergies or intolerances.
      In general there is a tendency to use less must support flags and to clarify their usage, this is intendended for this IG in a future release when the community has more experience with testing and balloting the IG.
      In this sense the extensions defined by the interprofessional working group EPR (IPAG) have no must support flags in the present version but are easily identified in the differential view of the artifact.
      The expectation is that alergy specialists tend to provide more detailed information applying these extended reaction details, whereas the common MD will document rather the must support attributes.
  • CH EPR mHealth (no description)
  • CH EMED, see description
    • The representation of the Medication Card document SHALL be embedded as a PDF in PDF/A-1 or PDF/A-2 format. The required elements in the PDF correspond to the minimum data set in the IPAG report. In the FHIR profiles, the flag mustSupport is set to true for these elements.

@oliveregger
Copy link
Contributor

oliveregger commented Nov 3, 2021

Definition von IHE nimmt als Basis für mustSupport R2:

@oliveregger
Copy link
Contributor

Stand heute AllergieIntoleranz: mustSupport Kreuzprodukt zwischen IPS und IPAG, nicht MinimalDataSet wie bei eMedikation

@oliveregger
Copy link
Contributor

Arbeitshypothese:

  • Minimal Data Set falls vorhanden von IPAG oder IPS als mustSupport in Schweizer IG's definieren.
  • Was man damit machen muss wäre Defintion von IHE als R2 Appendix Z:

R2 Required if known. If the sending application has data for the element, it is required to populate the element with a non-empty value. If the value is not known, the element may be omitted. A receiving application may ignore the information conveyed by the element. A receiving application shall not raise an error solely due to the presence or absence of the element.

translated by deepl:
Erforderlich, wenn bekannt. Wenn die sendende Anwendung über Daten für das Element verfügt, muss sie das Element mit einem nicht leeren Wert ausfüllen. Wenn der Wert nicht bekannt ist, kann das Element weggelassen werden. Eine empfangende Anwendung kann die durch das Element übermittelten Informationen ignorieren. Eine empfangende Anwendung darf nicht allein aufgrund des Vorhandenseins oder Nichtvorhandenseins des Elements einen Fehler auslösen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants