...
Question: Plans.Which parts of a plan can be adapted to the individual citizen? Both when the plan is activated and subsequently.
Answer: It is the definitions that are being rolled out. Technically, the things that have been transferred to CarePlan and ServiceRequest can be changed.
Question: Plans. Are titles and descriptions of plan definitions copied into the care plan when this is created?
Answer: No these are currently not copied.
Question: Plan. When a plan reaches an end date, will it then change CarePlan.status to “completed”? Is there automated support for this in the infrastructure?
Answer: No, this is not automated in the infrastructure. It is the employee solution's choice what to do when the plan reaches the end date. It is possible to schedule a status change that matches the end date via the ehealth-careplan status schedule field. A similar ehealth-episodeofcare status schedule is available on EpisodeOfCare.
Question: Starting rules. How should they be handled in the citizen solution and whether all options should be supported?
Answer: Not all options are supported in KAM. KAM uses a subset of the legal values in https://docs.ehealth.sundhed.dk/latest-released/igfhir/StructureDefinition-ehealth-plandefinition-definitions.html#PlanDefinition.action.relatedAction.relationship
The following values are currently used:concurrent,after-start,after,after-end
Question: Seamless activities
Answer: The platform sees the activities of the seamless group as separate activities and therefore separate tasks to be acknowledged.
Question: Response from e.g. the create-episode-of-care operation does not contain the created resources as shown in the example in the implementation guide, but only the individual transaction responses.
Answer: Remember to set the header ”
Prefer: return=representation"
Question: Measurement. NPU codes are locked to specific units of measurement. If, for example, a bathroom scale is set to pounds, then must it be converted to kg? Is it possible to record the original raw measurement value anywhere?
Answer: No. This is not possible. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1717436538/Preparing+and+Submitting+Measurements#Ensuring-Use-of-Proper-Units
Question: Measurement. How does an e.g. employee solution support the employee attaching a comment to received measurements/answers?
Answer: Consider using ehealth-communication. If clinical relevance then consider ehealth-clinicalimpression (DK.EHEALTH.SUNDHED.FHIR.IG.CORE\ehealth-clinicalimpression - FHIR v4.0.1)
Question: Triaging. Is it possible to see exactly which limit value led to the triaging result?
Answer: No this is currently not possible. However, the limit values are available on the observation.
Question: Triaging.Is the triaging creation of tasks synchronous or asynchronous?
Answer: Asynchronous - Measurement service receives synchronously, which however sends events to task service that takes the task asynchronously.
Question: Observation.code should be a certain small selection of codes. Most measuring devices provide observations for a lot of extra quality parameters. Should these be coded into Observation.ehealth-quality? And are there any guidelines for how to fill in Quality.qualityCode? For example, when to use which values of "Device Measuring Quality" (https://docs.ehealth.sundhed.dk/latest-releasedfhir/ig/ValueSet-ehealth-device-measuring-quality.html)?
Answer: No. It is currently not possible to additional quality parameters, and it is a fixed set of codes
Question: ClinicalImpression. How should the codes in the value-set ClinicalImpressionFindingCodes be interpreted about the triage colours red, yellow, and green when it comes to measurements?
Answer: The Color is on ClinicalImpression which is the result of the triaging. This then generates a Task with a given priority. There is no one-to-one mapping for priority. It is the rule in the library that sets priority. The rules in the Infrastructure use and consistent priority are as follows: STAT and ASAP as red, URGENT is yellow, and ROUTINE is green
Question: Consent. How is consent stored/edited in the infrastructure? How is this expected to be filled in? What are the processes around withdrawal and possibly regretting this?
Answer: Consent is described here: https://docs.ehealth.sundhed.dk/latest-released/igfhir/StructureDefinition-ehealth-consent.html . The infrastructure does not relate to the withdrawal of Consent. See https://docs.ehealth.sundhed.dk/latest-released/igfhir/StructureDefinition-ehealth-consent.html#enforcement-of-consent, . The Content status must be "active" for consent to be part of the controls. So possible to set the status to "rejected" or "inactive" upon withdrawal?
Question: Episode of care. Is there is place to indicate the name of an episode-of-care?
Answer: No there is no name or description in FHIR episode-of-care. Maybe diagnosis be used for the name.
Question: ServiceRequest. How long must a ServiceRequest be exceeded before a Task is created?
Answer: The task will be created by a job the following night (according to the timing specified). See also Adhering to Care Plans and Measurement Regimes and https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind + the +Scenes.
Question: ServiceRequest.code has cardinality 0..1 and ActivityDefinition.code has cardinality 1..1. Both have required binding on Activity Definition Code ValueSet. When a ServiceRequest references an ActivityDefinition, their codes will then be the same in all cases, and if so, why is there a difference in cardinality?
Answer: There should be no difference. ActivityDefinition.code is always set and copied to ServiceRequest.code and therefore in practice always set. So short answers: Yes ServiceRequest.code is always set.
Question: get-patient-procedures fail with "Invalid date compared to configured value" for some date ranges. What are the rules for valid start and end times for the operation?
Answer: There is a limit on the number of days back in time you can request in the request. This is currently not documented. It is currently set to a maximum of 30 days (MeasurentMaxAgeDays). This means that the start and end date of the request must be a maximum of the previous 30 days. There are no limitations in days in the future.
...