DK MedCom Condition List
1.0.0 - release
DK MedCom Condition List
1.0.0 - release
DK MedCom Condition List, published by MedCom. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-medcom-conditionlist/ and changes regularly. See the Directory of published versions
This page contains examples for different scenarios of the ConditionList document, where each example is a Bundle with different content.
Note: Examples are displayed in three formats: JSON, XML and TTL. In the project Shared Condition Overview, PLSP (Primærsektorens Leverandør Service PLatform) will only display documents in JSON format.
The first and second example, are examples of how the content of a ConditionList is expected to be inmost cases.
1st ConditionList can be seen as a minimum example. It contains one diagnosis for a patient, where two codes, a text, status and dates are included, but without the display values for the codes. The Composition includes the minimum required information.
2nd ConditionList can be seen as a maximum example. It contains three diagnoses for a patient, which illustrates how to include several condition within the same section in a Composition. Together the three diagnoses contain all the allowed elements for a condition. The Composition includes, besides the mandatory elements, an attester and author person. Only the Composition.event element is left out, since this is not relevant for the ConditionList.
As described on page for the MedComCondtionListCondition the quality of the registered diagnoses is not always as expected. However, it is decided to exchange the available information despite of the incompleteness. In the following examples, the Composition instances will include the minimum required information and it is mainly the content of the Conditions that varies.
3rd ConditionList contains a IPCP2 code (Condition.code.code), but without a display value (Condition.code.display) and a text (Condition.code.text) describing the diagnosis. Further, the status (Condition.category) of the diagnosis is current.
4th ConditionList contains a text (Condition.code.text) describing the diagnosis, a current status (Condition.category), onset (Condition.onsetDateTime) and recorded date (Condition.recordedDate). However, no codes (Condition.code.code) for the diagnosis is included.
5th ConditionList contains no code nor text describing the diagnosis (Condition.code). The only information for this diagnoses is the date it was registered in the GP's system (Condition.recordedDate) and the status (Condition.category).
6th ConditionList contains a code which isn't a SKS-D nor ICPC2 code, but a SNOMED CT code instead (Condition.code.code). No text is included (Condition.code.text). Further, a category (Condition.category) is included and the status is current (Condition.category).
7th ConditionList contains a code (Condition.code.code) without a system (Condition.code.system) and text (Condition.code.text).
Below is an example of a DocumentReference for the ConditionList standard. The content is based on the information from the 2nd ConditionList example. The DocumentReference is not meant to be exhanged, but is available if vendors wants to validate the metadata. This can be done by mapping the content of metadata to the DocumentReference and validating this against the IG.