Update StructureDefinition-dk-core-observation-intro.md

#95 and #96 are handled

input/pagecontent/StructureDefinition-dk-core-observation-intro.md

@@ -4,9 +4,9 @@ The Danish Core Observation profile is intended to represent observations for a
 * results of using clinical assessment tools such as APGAR
 * device measurements such as Pulse Oximetry data
 * observations obtained in clinical assesments such as abdominal tenderness
-* general health status
+* general health status such as pregnancy
+* social history and anamnesis (Please be aware, an Observation must only include more than one code, if each code is true for the observation that actually happened, and not several observation as a result of an investigation. In this case, the ClinicalImpression resource should be used.)
 
-> Note: HL7-Denmark are working on an Observation profile for vital signs. Expected release is in Q4 2023.
 
 #### Codes
 In a Observation resource, codes from CodeSystems are used to describe what is observed in the elements Observation.code.coding and Observation.component.code.coding. In these elements, multiple CodeSystems are specified to ensure similar use of relevant CodeSystems in a Danish context. Some observations may need to be grouped together to document critical observations, e.g. systolic and diastolic bloodpressure, which can be supported by the element Observation.component. [Click here for more information about Observation Grouping](http://hl7.org/fhir/observation.html#obsgrouping). 
@@ -17,12 +17,12 @@ Two or more Observation.code.coding may be assigned in the same Observation.code
 If the codings and units does not represent the same meaning, one instance of an Observation can be derived from another, as described in section [Observation derived from other Observation](#observation-derived-from-other-observation).
 
 None of the specified CodeSystems are required since each use case may call for different codes to represent the observations. The specified CodeSystems are included based on the [standard catalogue from the Danish Health Data Agency](https://sundhedsdatastyrelsen.dk/da/rammer-og-retningslinjer/om-referencearkitektur-og-standarder/standardkatalog), and Danish practice. In the following, some overall recommendations about the use of the code systems are provided:
-* NPU codes are the preferred first choice in official Danish health IT-systems. NPU mostly have laboratory codes.
-* LOINC codes are generally not recommended, for clinical areas that NPU covers, because they are overlapping without being modelled in exactly the same way. For clinical areas not covered by NPU, LOINC can be used. LOINC is an international code system, and is the first choice for many FHIR-observations around the world. This also means that Observation standard-profiles often use LOINC codes, and that interoperability use cases using equipment/wearables intended for markets intentionally, very well may have build-in LOINC codes.
-* IEEE codes are the internal codes of many devices see [https://www.iso.org/standard/37890.html](https://www.iso.org/standard/37890.html). If an original observation from a device is represented, HL7-DK recommends using its original layout including the IEEE codes. Read more in IHE Personal Connected Health [https://wiki.ihe.net/index.php/Personal_Connected_Health](https://wiki.ihe.net/index.php/Personal_Connected_Health).
-* SKS does have a few observation codes in use, most are found in the 'R' Hierarchy - see e.g. [https://medinfo.dk/sks/brows.php](https://medinfo.dk/sks/brows.php). HL7-DK does not recommend the use of SKS codes from the 'ZZ' hierarchy as FHIR observation-codes as they are codes for procedures. 
-* MedCom codes are Danish codes, that are not part of SKS, but have been necessary in Danish interoperability projects through time. They are sometimes referred to as kiap-codes or MCS codes. They can be found here: [https://medcom.dk/standarder/koder/laboratorieomraadet/](https://medcom.dk/standarder/koder/laboratorieomraadet/) or here: [https://kiap.dk/kiap/praksis/services/koder/iupackoder.php](https://kiap.dk/kiap/praksis/services/koder/iupackoder.php)
-* SNOMED CT codes are accepted in Denmark. SNOMED CT codes are relevant, for areas that NPU does not cover. Additionally, SNOMED CT is often used as a reference terminology, to give a common language of retrieval for data that have originally been defined or coded in some other way. If SNOMED CT is used as a reference terminology, it is often relevant to provide a SNOMED CT code, in addition to the original coding. This is also acceptable if the SNOMED CT concept is less granular than the original code, if each code is true for the observation that happened. 
+* NPU codes are the preferred first choice when communicating observations from the laboratory area. NPU contains few codes outside the laboratory area. NPU is recommended to use in the standard catalogue from the Danish Health Data Agency.
+* LOINC codes are generally not recommended, for clinical areas that NPU covers, because they are overlapping without being modelled in exactly the same way. For clinical areas not covered by NPU, LOINC can be used. LOINC is an international code system, and is the first choice for many FHIR-observations around the world. This also means that Observation standard-profiles often use LOINC codes, and that interoperability use cases using equipment/wearables intended for markets intentionally, very well may have build-in LOINC codes. LOINC is not recommended to use by the Danish Health Data Agency, but is included to support interoperability across countries in projects such as European Helath Data Space (EHDS).
+* IEEE codes are the internal codes of many devices see [https://www.iso.org/standard/37890.html](https://www.iso.org/standard/37890.html). If an original observation from a device is represented, HL7-DK recommends using its original layout including the IEEE codes. Read more in IHE Personal Connected Health [https://wiki.ihe.net/index.php/Personal_Connected_Health](https://wiki.ihe.net/index.php/Personal_Connected_Health). IEEE is recommended to use in the standard catalogue from the Danish Health Data Agency.
+* SKS does have a few observation codes in use, most are found in the 'R' Hierarchy - see e.g. [https://medinfo.dk/sks/brows.php](https://medinfo.dk/sks/brows.php). HL7-DK does not recommend the use of SKS codes from the 'ZZ' hierarchy as FHIR observation-codes as they are codes for procedures. SKS is recommended to use in the standard catalogue from the Danish Health Data Agency.
+* MedCom codes are Danish codes, that are not part of SKS, but have been necessary in Danish interoperability projects through time. They are sometimes referred to as kiap-codes or MCS codes. They can be found here: [https://medcom.dk/standarder/koder/laboratorieomraadet/](https://medcom.dk/standarder/koder/laboratorieomraadet/) or here: [https://kiap.dk/kiap/praksis/services/koder/iupackoder.php](https://kiap.dk/kiap/praksis/services/koder/iupackoder.php). MedCom codes are not recommended to use by the Danish Health Data Agency, but are included as they are often used in MedComs standards.
+* SNOMED CT codes are accepted in Denmark. SNOMED CT codes are relevant, for areas that NPU does not cover. Additionally, SNOMED CT is often used as a reference terminology, to give a common language of retrieval for data that have originally been defined or coded in some other way. If SNOMED CT is used as a reference terminology, it is often relevant to provide a SNOMED CT code, in addition to the original coding. This is also acceptable if the SNOMED CT concept is less granular than the original code, if each code is true for the observation that happened. SNOMED CT is stated to be usefull in the standard catalogue from the Danish Health Data Agency.
 
 #### Subjects and performers
 The primary use of this profile is to describe an observation performed on a patient. The patient must be represented using the [DkCorePatient](StructureDefinition-dk-core-patient.html) profile. However, it is still possible to select Observation.subject to be a Group, Device or Location. This is chosen to enable different uses of the profile e.g. a device calibration result is an observation of the device, not of the person that usually uses the device.