Provenance agent entity #166

mrinnetmaki · 2023-08-30T17:45:43Z

A proposal for the information custodian, expressed in both Provenance.who and Provenance.what.

Make the Provenance profile more generic, and add a separate profile for information custodianship (rekisterinpitäjä).

To keep track of how this was tested. Not to be included into the IG.

This reverts commit daa3cc7.

Just saving a snapshot before changing direction. Exploring whether the organization type should still be in `.agent.role`...

Also add some identifier types. And add .entity.agent as an example for the occupational healthcare.

I did not find a good way how to explain why to have these in the examples. The original idea was to illustrate how to make it more clear which agent the registry is relevant to, in case there would be more agents present in the same Provenance instance. This was discussed briefly with Kela, but I did not have good enough of a concept in my mind to be able to explain it.

The name custodian would be easily be mistaken to represent the custodian of a patient. Also, add some minor editorial changes.

Without the ugly hack the asterisks look bad on the profile listing page.

mrinnetmaki · 2023-08-31T17:39:54Z

@mikajylha, ready for final review.

mikajylha

One error that would need to be fixed. One small term issue.

Good work!

I see following issues with this:

entity.what is slightly mis-using indetifier type, to point to a code. Alternative would require use of extensions. Trade-off between a slight mis-use and another extension is reasonably balanced here.

The definition of the code system KanTa-palvelut - Potilasasiakirjan rekisteritunnus is document-based and doesnt seem to be a perfect fit for entity.what. However the contents of the codesystem and the general spirit fit well.

input/pagecontent/StructureDefinition-fi-base-information-custodian-intro.md

mikajylha · 2023-09-01T07:40:39Z

input/fsh/informationCustodian.fsh

+  * ^definition = "The status of the healthcare provider (*eArkisto - Rekisteripitäjän laji*), i.e., whether the provider is a public or private actor. The value for the identifier SHALL be 1 for public, 2 for private."
+  * ^short = "Public or private occupational healthcare provider"
+* agent[custodian].who.identifier.type = http://terminology.hl7.org/CodeSystem/v2-0203#PRN
+* agent[custodian].who.identifier.system = "urn:oid:1.2.246.537.6.202"


This is incorrect. Custodians are not in SOTE organisaatiorekisteri, they are in eArkisto - Rekisterinpitäjärekisteri

Examples need to be updated also.

(THL Codeserver has organization registries for different purposes, at least SOTE-Organisaatio, Rekisterinpitäjä and Apteekki).

Argh!

Any idea whether the example should use 1.2.246.10.32213086.19.2 Pirkanmaan hyvinvointialueen arkistonmuodostaja or 1.2.246.10.32213086.19.0 Pirkanmaan hyvinvointialueen rekisterinpitäjä?

https://koodistopalvelu.kanta.fi/codeserver/pages/codelist-hierarchy-page.xhtml?conceptCodeKey=200063048&versionKey=496&conceptCodeId=1.2.246.10.32213086.19.2

@mikajylha eArkisto - Rekisterinpitäjärekisteri seems to only include public sector organizations. How should the identifier system be expressed for the private organization?

Kanta Cda Header docs (2.2.17 ClinicalDocument.custodian – asiakirjan rekisterinpitäjä) :

Julkiset toimijat löytyvät eArkisto-Rekisterinpitäjärekisteristä. Yksityisten toimijoiden tietoja ei viedä lainkaan rekisterinpitäjärekisteriin. Rekisterinpitäjätietona käytetään yksityisten toimijoiden osalta palvelunantajatietoa (SOTE-organisaatiorekisterin Sektori 2 Yksityinen palvelunantaja, Sektori 3 Yksityinen itse ilmoitettu yksikkö tai koodiston Terveydenhuollon itsenäiset ammatinharjoittajat toimija). SOTE-organisaatiorekisterin osalta saa rekisterinpitäjänä käyttää vain terveydenhuollon toimintayksikköä.

That would mean that we need both code systems.

So for private the exact rule would be that when private then use SOTE organisaatiorekisteri and when public then use Rekisterinpitäjärekisteri.

Even further constraints could be introduced for private sector (regarding rule for "Terveydenhuollon toimintayksikkö only), that means this flag:

. ... but I'm sure we dont need to go that deep :) (writing here just for background).

Julkiset toimijat löytyvät eArkisto-Rekisterinpitäjärekisteristä. Yksityisten toimijoiden tietoja ei viedä lainkaan rekisterinpitäjärekisteriin. Rekisterinpitäjätietona käytetään yksityisten toimijoiden osalta palvelunantajatietoa (SOTE-organisaatiorekisterin Sektori 2 Yksityinen palvelunantaja, Sektori 3 Yksityinen itse ilmoitettu yksikkö tai koodiston Terveydenhuollon itsenäiset ammatinharjoittajat toimija). SOTE-organisaatiorekisterin osalta saa rekisterinpitäjänä käyttää vain terveydenhuollon toimintayksikköä.

Pitääkö siis tehdä kaksi vaihtoehtoa, julkisille toimijoille system olisi tuo rekisterinpitäjärekisteri ja yksityisille sote-organisaatiorekisteri?

Itse asiassa kolme, mukaan myös 1.2.246.537.6.203, Valvira - Terveydenhuollon itsenäiset ammatinharjoittajat

Any idea whether the example should use 1.2.246.10.32213086.19.2 Pirkanmaan hyvinvointialueen arkistonmuodostaja or 1.2.246.10.32213086.19.0 Pirkanmaan hyvinvointialueen rekisterinpitäjä?

Examples should point to_Rekisterinpitäjä_, thats most definitely the right one. (I dont understand the concept of Arkistonmuodostaja, its removed from kanta spec too (see 2.2.21.1 ClinicalDocument.participant – arkistonmuodostaja for "proof" that its no longer in use. It may have other purposes, but there shouldn't be any need for it in FHIR...). But I don't think we need to explicitly limit this to a specific hiearchy level...

Pitääkö siis tehdä kaksi vaihtoehtoa, julkisille toimijoille system olisi tuo rekisterinpitäjärekisteri ja yksityisille sote-organisaatiorekisteri?

Kyllä.

Itse asiassa kolme, mukaan myös 1.2.246.537.6.203, Valvira - Terveydenhuollon itsenäiset ammatinharjoittajat

En löydä tätä CDA Header dokkarista. @mikatuomainen Osaatko kommentoida voiko tätä käyttää rekisterinpitäjänä?

The more appropriate GDPR term

The identifier may come from three different registers, depending on the type of the information custodian.

mikajylha · 2023-09-01T13:46:02Z

1.2.246.537.6.203 was new information for me. Using it seems consistent, even if its missing from Kanta CDA Header spec.

I wasn't able to find a way to target the slicing properly and definitely otherwise. This feels more logical too.

mrinnetmaki · 2023-09-02T21:25:18Z

@mikajylha I did find the code set 1.2.246.537.6.203 through the CDA Header spec, in a way.

2.2.17 ClinicalDocument.custodian – asiakirjan rekisterinpitäjä
Rekisterinpidosta vastaavan rekisterinpitäjän OID-koodi ja nimi.

Julkiset toimijat löytyvät eArkisto-Rekisterinpitäjärekisteristä. Yksityisten toimijoiden tietoja ei viedä lainkaan rekisterinpitäjärekisteriin. Rekisterinpitäjätietona käytetään yksityisten toimijoiden osalta palvelunantajatietoa (SOTE-organisaatiorekisterin Sektori 2 Yksityinen palvelunantaja, Sektori 3 Yksityinen itse ilmoitettu yksikkö tai koodiston Terveydenhuollon itsenäiset ammatinharjoittajat toimija). SOTE-organisaatiorekisterin osalta saa rekisterinpitäjänä käyttää vain terveydenhuollon toimintayksikköä.

mrinnetmaki added 5 commits August 28, 2023 13:54

Rework custodian profile

68a4845

Make the Provenance profile more generic, and add a separate profile for information custodianship (rekisterinpitäjä).

Add a test file for data custodian profile

daa3cc7

To keep track of how this was tested. Not to be included into the IG.

Revert "Add a test file for data custodian profile"

17888e9

This reverts commit daa3cc7.

Work in progress...

002d400

Just saving a snapshot before changing direction. Exploring whether the organization type should still be in `.agent.role`...

Put organization role in .agent

b19a757

Also add some identifier types. And add .entity.agent as an example for the occupational healthcare.

mrinnetmaki requested a review from mikajylha August 30, 2023 17:45

Add additional register specifiers

c238924

jpriebe-epic mentioned this pull request Aug 31, 2023

Provenance register elements can probably be covered by standards #88

Closed

mrinnetmaki added 7 commits August 31, 2023 18:45

Fix slice names

ebfe1b6

Fix slice name and the new identifier system

00d5948

Add intro text for information custodian profile

a640c40

Change the profile name to information custodian

6257aa9

The name custodian would be easily be mistaken to represent the custodian of a patient. Also, add some minor editorial changes.

Fix italics in description

3d2fdf3

Without the ugly hack the asterisks look bad on the profile listing page.

Add a small editorial fix for profile description

01c7d5d

mrinnetmaki mentioned this pull request Aug 31, 2023

Laajennus RegisterSpecifier: Rekisterin tarkenteen tietotyyppi + rakenne #135

Closed

This was linked to issues Aug 31, 2023

Provenance register elements can probably be covered by standards #88

Closed

Kela: Provenance luku 8.18.1 #141

Closed

Laajennus RegisterSpecifier: Rekisterin tarkenteen tietotyyppi + rakenne #135

Closed

mikajylha requested changes Sep 1, 2023

View reviewed changes

mrinnetmaki added 2 commits September 1, 2023 13:22

Fix data processor to data controller

cafb13a

The more appropriate GDPR term

Allow for multiple custodian types

ac0217a

The identifier may come from three different registers, depending on the type of the information custodian.

mikajylha approved these changes Sep 1, 2023

View reviewed changes

Separate profiles for custodian types

271a0c6

I wasn't able to find a way to target the slicing properly and definitely otherwise. This feels more logical too.

mrinnetmaki merged commit 0744051 into master Sep 2, 2023
1 check passed

mrinnetmaki deleted the provenance-agent-entity branch September 2, 2023 21:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provenance agent entity #166

Provenance agent entity #166

mrinnetmaki commented Aug 30, 2023

mrinnetmaki commented Aug 31, 2023

mikajylha left a comment •

edited

Loading

mikajylha Sep 1, 2023

mrinnetmaki Sep 1, 2023

mrinnetmaki Sep 1, 2023

mikajylha Sep 1, 2023 •

edited

Loading

mrinnetmaki Sep 1, 2023

mrinnetmaki Sep 1, 2023

mikajylha Sep 1, 2023

mikajylha Sep 1, 2023 •

edited

Loading

mikajylha commented Sep 1, 2023

mrinnetmaki commented Sep 2, 2023

Provenance agent entity #166

Provenance agent entity #166

Conversation

mrinnetmaki commented Aug 30, 2023

mrinnetmaki commented Aug 31, 2023

mikajylha left a comment • edited Loading

Choose a reason for hiding this comment

mikajylha Sep 1, 2023

Choose a reason for hiding this comment

mrinnetmaki Sep 1, 2023

Choose a reason for hiding this comment

mrinnetmaki Sep 1, 2023

Choose a reason for hiding this comment

mikajylha Sep 1, 2023 • edited Loading

Choose a reason for hiding this comment

mrinnetmaki Sep 1, 2023

Choose a reason for hiding this comment

mrinnetmaki Sep 1, 2023

Choose a reason for hiding this comment

mikajylha Sep 1, 2023

Choose a reason for hiding this comment

mikajylha Sep 1, 2023 • edited Loading

Choose a reason for hiding this comment

mikajylha commented Sep 1, 2023

mrinnetmaki commented Sep 2, 2023

mikajylha left a comment •

edited

Loading

mikajylha Sep 1, 2023 •

edited

Loading

mikajylha Sep 1, 2023 •

edited

Loading