Dokumentere identifiserte krav og behov

[thomiz]

VkpObservation krav og behov

Det er identifisert følgende krav knyttet til observasjoner som skal deles via Velferdsteknologisk Knutepunkt.

Krav til Samhandling

Observasjonene skal foreløpig deles internt i en virksomhet (kommune).

• Observasjoner skrives til VKP fra DHO system via FHIR RESTful API
• Observasjoner skrives fra VKP til kommunal EPJ via proprietært API for EPJ systemet

På sikt er målbildet at observasjoner skal deles mellom virksomheter gjennom et API fra VKP.

• Observasjoner søkes og leses fra VKP via FHIR RESTful API

Krav til innhold i observasjoner

• Subject identifiseres med FNR/DNR/FHNR
• Performer identifiseres med FNR
• Angi frivillig slice for SNOMED koder observation.code
  • Angi SNOMED CT kode som tilsvarer LOINC "magic value" for vitale parametere

Nasjonal og internasjonal standardisering

• Vitale parametre profiler fra FHIR R4 benyttes der det er mulig
  • no-domain profiler benyttes der det er mulig

[thomiz]

Dokumentasjon for hvordan koding med SNOMED og LOINC i tospann fungerer i VkpOpbservation

Når vitale parametere utveksles ved hjelp av HL7 FHIR

• LOINC "magic value" er påkrevd i vital-signs profilene og er alltid med i utvekslingen
• En SNOMED CT kode som representerer 1:1 mapping LOINC "magic value" kan være med i tillegg til LOINC koden, for å understøtte semantisk samhandling i Norge hvor LOINC brukes i liten grad i tjenesten
• Mer spesifikke SNOMED CT koder kan komme i tillegg for å uttrykke mer spesifikk/detaljert informasjon enn det LOINC "magic value" uttrykker alene.
  • I de tilfeller det kodes mer spesifikke SNOMED CT koder må den mer spesifikke koden være en spesialisering av den oppgitte SNOMED koden som er 1:1 mot LOINC "magic value"
  • I de tilfeller der de mer spesifikke SNOMED CT kodene uttrykker mening som hører inn under Observation.bodySite eller Observation.method, bør bodySite og method inneholde tilsvarende koder

[thomiz]

Beskrive konsekvensene for søk og samhandling ved bruk av prinsippene beskrevet over.

[rockphotog]

Bør kommer frem at har man en mer spesifikk SCT-kode MÅ man også ha med "1:1-SCT-koden (!), stemmer ikke dette?

[thomiz]

Absolutt @rockphotog , det må presiseres.

[thomiz]

Arbeidet med prinsippet tas ut i egen issue

Legges under no-domain siden det er generelt for vitale parametere:
Issue for dette i best practice arbeidet

The use of LOINC "magic value" in combination with SNOMED CT codes

For exchanging vital signs observations using HL7 FHIR in Norway

Vital signs observations have predefined profiles defined by HL7 International. The goal of the HL7 vital signs profiles are:

The FHIR Vital Signs profile sets minimum expectations for the Observation resource to record, search and fetch the vital signs associated with a patient that include the primary vital signs plus additional measurements such as height, weight and BMI.

These profiles defines a LOINC "magic value" for use in Observation.code to tell what is being measured. The use of LOINC is problematic in Norway as the CodeSystem is not in common use by clinicians and the systems generally don't support LOINC codes. In Norway we would suggest to always exchange vital signs observations with an additional SNOMED CT code for better semantic interoperability. The following principles have been defined for the use of LOINC magic values and additional SNOMED CT coding in the Observation.code element:

1. A LOINC "magic value" is mandatory according to the HL7 vital signs profile
2. A SNOMED CT code representing 1:1 mapping to the LOINC "magic value" can be included in addition to the LOINC code to support better semantic interoperability in Norway
3. Any number of more specific SNOMED CT concept can be added to express more details concerning the observation
   1. When a more specific SNOMED CT code is added it must be a specialization of the SNOMED CT code defined as a 1:1 mapping to the LOINC "magic value"
   2. When a more specific SNOMED CT code is included the defined 1:1 mapping SNOMED CT code is mandatory
   3. In some cases a more specific SNOMED CT code can express semantics that could fit in the Observation.bodySite or Observation.method elements. In these cases the information should be included in the bodySite and method elements as well

[thomiz]

Duplikat av Issue for dette i no-domain arbeidet