michaelonken / dmp_diabetes Goto Github PK

[via data4life]

Pulse status: Here, one could perhaps use the SNOMED 8499008 (“Pulse, function (observable entity)“) - in line with Observation pattern 1 from the FHIR spec).

[via data4life]

section hba1c: The two allowed profiles both enforce the same Observation.code (SNOMED 43396009) and differ only in the units. Could these not be combined into a single profile that allows both units types? Alternatively, LOINC might offer codes that distinguish between the two types of measurements (e.g. LOINC 4548-4 for the relative concentration) so one avoids to profiles with the same code.

[via data4life]

The sub-slice secondaryDisease must contain at least one Condition resource. Is it possible that the patient does not have any secondary disease?

[via data4life]

For trainings that have been arranged (“veranlasst”), a ServiceRequest resource might be preferable. In particular, ServiceRequest.code can directly hold a code for the training that has been requested.

[via data4life]

• DDG DMP Enrollment Reason extension: Could be Condition resource
• DDG DMP Relevant Events extension: Could be Condition resource
• DDG DMP Emergency Inpatient Treatment Events extension: Could be Observation resource
• DDG DMP Severe Hypoglycemia Events: Could be Observation resource
• DDG DMP Opthalmic Retinal Examination: Could be Procedure resource (or Observation?)

[data4life]

If we understand the MedicinalProductContraindication resource correctly, it is meant to indicate general properties of a medication for regulatory, rather than a specific contraindication for an individual patient (it also has the lowest possible maturity level)). Depending on the reason for the contraindication, e.g. AllergyIntolerance could thus be preferable.

It is desirable to build upon existing KBV (base profiles or tele monitoring profiles as probably preferred by DDG)

• in order to take over best practice for German market
• in order to hand over the DMP specification as input to KBV for integration with ePA

Right now there is an unsolved problem with the sushi toolchain toolchain when referencing simplifier resources (like the KBV ones above) that do not contain full snapshot data. A solution is in the making...

[via data4life]

See same discussion as in #11

[via data4llife]

DDG DMP Treatment Planning extension: Could be (partly) distributed to various resources. E.g whether the patient has reached the target HbA1c target value could be an Observation, and the documentation and foot inspection intervals could perhaps be captured with a singe CarePlan resource (as separate entries in CarePlan.activity, with the schedule given in CarePlan.Activity.detail.scheduled).

Please add SNOMED code: 414925007

Please add Praxis ID to the practitioner or an additional Praxis Profile that links to Practitioner Profile.

[via data4life]

Albumin excretion: POssibly SNOMED 365801005 (“Finding of albumin level (finding)“) or a child term, or SNOMED 71628007 (“Abnormal presence of albumin (finding)“) could be used here

[via data4life]

Further Risk Ulcus: From the spreadsheet, it was not clear whether this directly relates to Ulcus or is more general (the spreadsheet entry is just “Weiteres Risiko”).

Please add the variable deathDate as an optional parameter to the Resource Profile: DDG DMP Patient.
Thanks!

[via data4life]

Past trainings could also be captured as Procedure resources (cf spec: “Procedures are actions that are intended to result in a physical or mental change to or for the subject (e.g. surgery, physiotherapy, training, counseling)“). For missed appointments (i.e. things known to have been scheduled but not carried out), one could set Procedure.status to “not done”.

[via data4life]

It seems that “not done” answers in the DMP questionnaire is typically captured as a code in the resource referenced in the corresponding section of the Composition. Might it be better to indicate “not done” by simply leaving out the corresponding Composition section, like the International Patient Summary (IPS) does it? Or, alternatively, allowing the standard data-absent-reason extension to be added to that Composition section (allows passing e.g. the code not-performed)?

[via data4life]

Ulcus: Might it be possible to use one of the child-codes of SNOMED 56208002 (“Ulcer (morphologic abnormality)“) here? Either as the result (with a generic code for examniation) or as the code itself, with value[x] left out (cf. Observation code patterns 1 & 4 from the FHIR spec)

[via data4life]

DDG DMP Medical History eGFR profile (Estimated Glomerular Filtration Rate): For clarity, it might be worth considering explicitly spelling out the full name rather than just writing “eGFR” since “EGFR” is also the acronym for a gene often involved in cancer (Epidermal growth factor receptor).

[via data4life]

The Composition.section:medications slice requires at least one entry. Is it not conceivable (though unlikely) that the patient is not taking any medication at all?