Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fine-tune TURVAKIELTO text #137

Merged
merged 4 commits into from
Jun 29, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
CodeSystem: SecurityLabelCS
Id: SecurityLabelCS
Title: "Finnish CodeSystem for security labels"
Description: "This is the CodeSystem for security labels in accordance with finnish authorities"
Description: "This is the CodeSystem for security labels in accordance with finnish authorities."
* ^status = #active
* ^experimental = false
* #TURVAKIELTO "Turvakielto"
Expand Down
9 changes: 9 additions & 0 deletions input/pagecontent/CodeSystem-SecurityLabelCS-intro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
The TURVAKIELTO label is the first code to be added into the code system. Many other codes are
likely to be added, including codes for other
|data protection preferences in the Suomi.fi infrastructure](https://dvv.fi/en/data-protection) and
codes for
[permissions for health data sharing from the Kanta system](https://www.kanta.fi/en/consent-and-denials-of-consent-to-data-sharing).
Implementer feedback regarding this approach and regarding codes that should be added is
appreciated!
{:.stu-note}

10 changes: 10 additions & 0 deletions input/pagecontent/Patient-patient-with-turvakielto-intro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
The TURVAKIELTO label is the first code to be added into the
[Finnish CodeSystem for security labels](CodeSystem-SecurityLabelCS.html). Many other codes are
likely to be added, including codes for other
|data protection preferences in the Suomi.fi infrastructure](https://dvv.fi/en/data-protection) and
codes for
[permissions for health data sharing from the Kanta system](https://www.kanta.fi/en/consent-and-denials-of-consent-to-data-sharing).
Implementer feedback regarding this approach and regarding codes that should be added is
appreciated!
{:.stu-note}

59 changes: 31 additions & 28 deletions input/pagecontent/StructureDefinition-fi-base-patient-intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,22 +20,22 @@ for a person are

The unique identifier is the national person identifier.

##### Patient identifier
#### Patient identifier

There are two versions of the national person identifier for people living in Finland.

The [official Personal Identifier Code](https://dvv.fi/en/personal-identity-code) (PIC, also known
as _HETU_) is granted by the Digital And Population Data Services Agency. The `oid` for the
The [official Personal Identifier Code](https://dvv.fi/en/personal-identity-code) (**PIC**, also
known as _HETU_) is granted by the Digital And Population Data Services Agency. The `oid` for the
official PIC is `1.2.246.21`.

When an official PIC is not known or cannot be used for other reasons, a system may generate a
[Temporary Identifier](https://www.kanta.fi/en/system-developers/test-etiquette#Temporary%20identifier).
[**temporary identifier**](https://www.kanta.fi/en/system-developers/test-etiquette#Temporary%20identifier).
There are several ways to create an `oid` for the temporary identifier. The most typical ones are
described in
[ISO OID-yksilöintitunnuksen käytön kansalliset periaatteet sosiaali- ja terveysalalla](https://www.hl7.fi/hl7-rajapintakartta/iso-oid-yksilointitunnuksen-kayton-kansalliset-periaatteet-sosiaali-ja-terveysalalla/)
document (in Finnish).

There are two generally used methods to create a temporary identifier OID.
There are two generally used methods to create a temporary identifier `oid`.

1. `1.2.246.10.<organization>.22.<year>`, where `<organization>` is the official identifier
(_y-tunnus_) of the organization and `<year>` the year when the temporary identifier is generated.
Expand All @@ -46,7 +46,7 @@ the organization in which the temporary identifier is created.
The first method is
[recommended](https://yhteistyotilat.fi/wiki08/display/JULPOKY/7+Potilaan+perustiedot#id-7Potilaanperustiedot-7.1Henkil%C3%B6nyksil%C3%B6intitiedot).

The identifiers are presented to human readers in the 11 character format, without any oid
The identifiers are presented to human readers in the 11 character format, without any `oid`
information.

When a PIC is used for a Patient instance, the value of the `identifier.use` field SHOULD be
Expand All @@ -61,7 +61,7 @@ In addition to person identifiers for people living in Finland, systems may use
that have a special range in the PIC format (the eighth character is `9`). For instance,
`020516C903K`.

##### Other identifiers
#### Other identifiers

Other identifiers can also be used to identify the patient. In many cases the national patient
identifier is not required. In these cases systems SHOULD assign another unique identifier for
Expand All @@ -70,22 +70,6 @@ SHOULD still be the same when the same app asks for the patient information mult

#### Additional Information

##### Municipality vs address information

Municipality of residence is represented with MunicipalityCode extension. Municipality means in
this context the municipality which is registered as the primary residence location. The
municipality of residence is always registered by the
[Digital and Population Data Services Agency](https://dvv.fi/en/municipality-of-residence). In most
cases the address information contains the same information presented in MunicipalityCode extension
but there are situations where `address.city` is not the same as the value in the extension.
Address is better understood as contact address. More information about the subject can be found on
[Home municipality](./StructureDefinition-municipality-code.html).

The distiction between these two different location types is important e.g. when patient is being
transferred from primary care to secondary care via referral. In these cases the secondary care
unit invoices the primary care service provider but patient may recieve infromation about the given
care via mail to address which is not located in municipality of recidence.

##### Name

Systems SHOULD populate the `.name.text` field and clients SHOULD use that version of the name,
Expand All @@ -100,17 +84,36 @@ do not share names or any demographic information by default.
Both time of birth and time of death SHOULD be recorded with the time component, if known. If the
time of day is not known, the date SHALL be recorded as a date only, without the time component.

The birth time, when known, SHALL be recorded using the
The birth time, when recorded, SHALL be recorded using the
[standard extension](http://hl7.org/fhir/extensions/StructureDefinition-patient-birthTime.html).

#### Non-disclosure for personal safety
### Municipality vs address information

DVV may grant a [non-disclosure for personal safety](https://dvv.fi/en/non-disclosure-for-personal-safety).
This is communicated by `TURVAKIELTO` security label.
Municipality of residence is represented with MunicipalityCode extension. Municipality means in
this context the municipality which is registered as the primary residence location. The
municipality of residence is always registered by the
[Digital and Population Data Services Agency](https://dvv.fi/en/municipality-of-residence). In most
cases the address information contains the same information presented in MunicipalityCode extension
but there are situations where `address.city` is not the same as the value in the extension.
Address is better understood as contact address. More information about the subject can be found on
[Home municipality](./StructureDefinition-municipality-code.html).

#### Presenting guardian information
The distiction between these two different location types is important e.g. when patient is being
transferred from primary care to secondary care via referral. In these cases the secondary care
unit invoices the primary care service provider but patient may recieve infromation about the given
care via mail to address which is not located in municipality of recidence.

### Presenting guardian information

In some cases, a guardian could be appointed to the patient if the patients is for ex. incapable of
managing one's matters due to an illness. In these situations, the guardian's information SHOULD be
presented with [RelatedPerson](http://hl7.org/fhir/R4/relatedperson.html) resource with the
relationship type [GUARD](http://hl7.org/fhir/R4/v3/RoleCode/cs.html#:~:text=3-,GUARD,-guardian).

### Non-disclosure for personal safety

The Digital and Population Data Services Agency DVV may grant a
[non-disclosure for personal safety](https://dvv.fi/en/non-disclosure-for-personal-safety).
This is communicated by the
[`TURVAKIELTO`](CodeSystem-SecurityLabelCS.html#SecurityLabelCS-TURVAKIELTO) security label (see
[an example](Patient-patient-with-turvakielto.html)).
9 changes: 9 additions & 0 deletions input/pagecontent/ValueSet-SecurityLabelVS-intro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
The TURVAKIELTO label is the first code to be added into the value set. Many other codes are likely
to be added, including codes for other
|data protection preferences in the Suomi.fi infrastructure](https://dvv.fi/en/data-protection) and
codes for
[permissions for health data sharing from the Kanta system](https://www.kanta.fi/en/consent-and-denials-of-consent-to-data-sharing).
Implementer feedback regarding this approach and regarding codes that should be added is
appreciated!
{:.stu-note}

4 changes: 2 additions & 2 deletions input/pagecontent/terminology.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,8 @@ Many of these terminologies are not maintained by HL7 Finland, rather they are p
maintained elsewhere and included into this implementation guide to raise awareness of their
existence.

This version of this implementation guide does not define any terminologies. There are other, more
use case specific implementation guides that may define terminologies for their use cases. See for
In addition to the terminologies defined in this implementation guide, there are other, more use
case specific implementation guides that may define terminologies for their use cases. See, for
instance:
* Both the [Finnish Appointment IG](https://simplifier.net/finnishappointment) and the
[Finnish Scheduling IG](https://simplifier.net/finnishschedulingr4/) for scheduling
Expand Down