Finnish FHIR Base Profiles
Home Page: https://hl7.fi/fhir/finnish-base-profiles/
License: Creative Commons Zero v1.0 Universal
Couldn't this be instead represented by Patient.communication.language?
This is more portable, and I think could accomplish the same logic. If language =/= local language, interpreter needed.
Open to being convinced on this one - maybe there's some specifics in operations that make sense (e.g. every non-Finnish speaker doesn't need an interpreter so this should be documented separately)
perustelu: kommentti: profiilista viitatun RegistrySpecifier laajennuksen kuvaukseen: ” Extension Register Specifier (Rekisterin tarkenne in finnish) (Required for Kanta Medical Records queries).”, tällä on muutakin merkitystä kuin vain Medical Records kyselyt, on myös asiakirjan metatieto (ja nyt Provenancesta viitatattavan rekisterinpitäjän tieto). Tämäkin oli jo kommenttina lausuntokierroskommenteissamme.
korjausehdotus: tekstissä pitää huomioida myös asiakirjan/resurssin metatietomerkitys, ei vain MR kyselyt
kommentti: rekisterintarkenteelle olisi hyvä olla paikka myös nimelle, vaatisi siis complex laajennuksen jossa tunnisteen lisäksi nimi
kommentti: käytettävät koodistot olisi hyvä olla määriteltynä/mainittuna itse laajennuksessa, ei määriteltynä vain esimerkissä. Tämäkin oli jo kommenttina lausuntokierroskommenteissamme.
We should add examples of each of the defined profiles.
For some reason the Examples page does not show the navigation menu, just the empty yellow box...
Negative Encounter (luku 8.3.1)
perustelu: nyt ei ole määritelty miten saadaan viitattua palvelutapahtumaan FHIR resurssista, josta ei ole viittausta Encounter resurssiin (jolla palvelutapahtuma ilmaistaan). 'Tämä olisi tärkeää ratkaista kansallisesti, ettei tule useita erilaisia ratkaisuja. Tätä käytiin eritoten kommenttien jälkeisissä läpikäynneissä, jossa kohta tarkentui uudelleen määrittelyn ohessa. Toimme alla olevan kommentin mielestämme selkeästi näissä läpikäynneissä esiin.
korjausehdotus: pitää määritellä tapa ilmaista viittaus palvelutapahtumiin myös resursseille, joista ei viitata Encounter-resurssiin
kommentti: olisi hyvä myös ottaa kantaa, voiko viittauksen palvelutapahtumaan tehdä/onko sallittua viitata pelkällä Reference tietotyypin identifier-elementillä (Identifier-tietotyyppi) ilman että ottaa koko Encounter resurssin käyttöön
Markdown text is not in-sync with the actual example. It contains category codes that are not according to the profile.
The page renders way too wide.
This is due to the <p> tag not being closed properly.
THL spec defines adverse effect in somewhat similar form than in diagnosis. It would be nice to have them in the profile.
When name differs from code.display
code.display MUST be the original name from the codesystem and code.text MAY contain adjusted name for the diagnosis.
In Epic's current FHIR implementation of conditon, we build code.display from the user-facing display name and do not constrain it to the codeset value. We do not populate code.name. Do we really need to constrain the display name if there's a codeset?
Introssa esiteltävä mitä koodistoa mikäkin koodi on, erityisesti kryptiset numeroarvokoodit ja oidit.
Tämä issue vaatii purkua, pitää käydä kaikki resurssit läpi. Tarvitaanko monta issueta?
Tarkennus: Conditionista on se toinen category: problem-list-item, mutta tämä issue koskettaa enemmän encounter-diagnosis -asiaa. En ole vielä pohtinut, millä tavalla tämä suhteutuu problem-list -puoleen.
Voidaanko tavoitella samaa laajuutta mikä HILMOn ja potilastiedon arkiston diagnoosi määrittelyissä? Tämä vaikuttaisi vaativan extensioneja.
Mitä Conditionilla halutaan ilmaista? Pelkkiä diagnooseja vai lisäksi myös käyntisyitä? Miten erotellaan diagnoosi ja käyntisyy toisistaan?
code-kenttään diagnoosin syykoodi (tai käyntisyyn ainokainen koodi). Voisiko mennä näin?
"code": {
"coding": [
{
"system": "urn:oid:1.2.246.537.6.1.1999",
"code": "A00.1",
"display": "Klassinen kolera"
}
]
},Seuraavat voisi määritellä (luultavasti vaativat laajennusta):
Entäs miten mallinnetaan päättyminen, mukaan lukien päättymisen syy?
Toteaja voidaan ilmaista participant:lla jonka function on author
Koodistojen osalta kansallisesti vaaditut icd-10 ja ICPC. Lisäksi varmaan snomed myös.
There are national requirements for storing profession information. I can't find this from the base spec. Should we include this in the profile?
For details see eg. hilmo-guide Chapter 3.2.
THL:
Profiiliin kannattaisi lisätä asiakkaan pankkiyhteystiedot, esim. vastaavalla rakenteella kuin Sosmeta-palvelun Pankkiyhteys-tietokomponentissa. Tämä olisi todennäköisesti hyödynnettävissä myös muissa profiileissa kuin Patient - yleinen laajennus osana Suomen pohjaprofiileja?
Configure the file https://github.com/fhir-fi/finnish-base-profiles/blob/master/input/ignoreWarnings.txt to make the QA report cleaner.
Some examples here: https://github.com/FHIR/sample-ig/blob/master/input/ignoreWarnings.txt
For instance:
[ ] examples from Kanta PHR use references to resources that are not included. This is OK, we don't need the examples to be complete working resource sets. We can ignore those warnings, on a case by case basis, after evaluation.
[ ] examples from Kanta PHR use clearly imaginary references like http://terminology.own.com. Is is safe to ignore warnings about these.
viittaus FiBaseReasonForCare viittaus pitää olla selkempi, esim. FI Base Reason for Care (encounter-diagnosis and reason for visit) profile
I just noticed there is a new project regarding scheduling in IHE, in cooperation with the Argonaut project.
https://build.fhir.org/ig/IHE/ITI.Scheduling/
Found this in https://healthcaresecprivacy.blogspot.com/2022/10/it-infrastructure-fall-2022.html.
New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot.
Worth paying attention to.
Muistio kokouksesta:
perustelu: tilapäisen yksilöintitunnuksen muodostaminen ei rajaudu pelkästään oppaassa kuvattuun tapaan (oid + 11 character format), tämä pitäisi tuoda selkeämmin esiin. Vastauskommenttidokumentissa viitataan myös rakenteisen potilastiedon kirjaamisoppaaseen, tämä ei välttämättä ole hyvä asia ja voikin kyseenalaistaa, onko ok rajautua pohjaprofiilissa vain rakenteisen kirjaamisen oppaan sääntöihin tai potilastiedon arkiston määrittelyihin. Tämäkin oli jo kommenttina lausuntokierroskommenteissamme.
korjausehdotus: tuotava selkeästi esiin, että oppaassa kuvatut tavat ovat yksi tapa tuottaa tilapäinen yksilöintitunnus mutta on muitakin sallittuja tapoja (oid osan muodostaminen JHS159 mukaan organisaation solmuluokan jälkeen organisaation vapaasti päätettävissä, myöskään 11 merkin muoto ei ole pakollinen). Kanta-kontekstissa on toimittajia, jotka eivät pysty täyttämään nyt kuvattua tapaa.
Miten mallinnetaan toimenpiteen lisätoimenpiteet?
Esim. "ZXC96 Robotin käyttö leikkauksessa". Näitä voi olla yhdellä toimenpiteellä monta.
This seems really specific to one concept case and I'm not sure it belongs in a specification. I don't see why it would need to be it's own extension.
Google turns up one specific diagnosis code that corresponds to endocrinological Disorder:
Something I'm missing here? Just looks like an example of something you could represent with Condition.
https://www.hl7.fi/fhir/finnish-base-profiles/1.0-rc2/StructureDefinition-fi-base-patient.html
Format looks weird on this page.
PIC looks like a HETU (Finnish national ID), but I haven't heard it referred to this way. Maybe we're just weird in Apotti referring to it this way, but probably worth adding a synonym.
We support this in Apotti today.
Its clearly a category
Intro text says "AR/YDIN - Toimenpiteen tyyppi" use: procedure.code
Examples have it right
"category" : {
"coding" : [
{
"system" : "urn:oid:1.2.246.537.6.601",
"code" : "TOI"
}
]
},
perustelu: Use of non-disclosure information on kuvattu Turvakielto-tiedon antamista. Turvakielto koskee vain osoitetietoja, kuten luvusta linkatussa DVVn sivussa kerrotaan (”Turvakielto on poikkeuksellinen toimi, jolla rajoitetaan osoitetietojesi luovuttamista väestötietojärjestelmästä. Kun sinulla on turvakielto, tieto osoitteestasi ja kotikunnastasi voidaan luovuttaa vain sellaisille viranomaisille, jotka saavat käsitellä turvakiellon alaisia tietoja.”). Oppaan luvussa sen kuvataan kuitenkin koskevan myös nimeä (”Finnish citizens that have requested name and address protection”). Lisäksi FHIR koodiston http://terminology.hl7.org/CodeSystem/v3-Confidentiality koodi R on varattu nyt tätä tietoa varten, vaikka sille voisi olla yleisempääkin käyttöä. Tämäkin oli jo kommenttina lausuntokierroskommenteissamme.
korjausehdotus: Turvakielto koskee vain osoitetietoja, viittaus nimitietoon pitää poistaa oppaasta.
Practitioner.identifier:Terhikki
Ok. We store this ID in Apotti and can support this today.
Practitioner.identifier:SSN
Is this just HETU?
Practitioner.identifier:SV
Can you give more info on this identifier? I want to make sure we support this today in Apotti's system
Currently one of the examples is marked as an example of the base FHIR resource, not the profile specified in this implementation guide. Therefore this example is not listed as one of the examples of the FiBaseProcedure profile. Is this intentional?
Immunization ja siellä "encounter" : {
"reference" : "Encounter/id-for-palvelutapahtuma"
Eli voisiko viitata palvelutapahtumaan reference-elementin sijaan suoraan palvelutapahtumaan identifier-elementistä? Jos voi, niin sen voisi tuoda esiin oppaassa.
Luku 1.2: ”In many cases, the HL7 FHIR standard allows for several ways to implement a functionality. There are increasing concerns that without a coordinated approach implementers will choose different ways to implement some features, and this will lead to challenges for interoperability. This implementation guide attempts to define a consensus within the Finnish FHIR implementers on which ways we have considered the best fit for use cases in Finland.”
tekstissä mainitaan functionality, käytännössä perusprofiileissa otetaan kantaa vain tietosisältöihin (data content), ei miten tietoja liikutellaan kohdistettava teksti vain tietosisältöihin, toiminnallisuuttahan tässä oppaassa ei määritellä lainkaan
Is Not Authored by a medical doctor
Is not authored by a medical doctor (Käyntisyy)
Some conditions are very much like diagnosis but the asserter is not a medical doctor. THL specification identifies these as käyntisyy.
Couldn't this be covered by the standard element Condition.Asserter with a simple rights check?
It's not a core requirement but it is standard and I think fits the needs of what you're trying to do here.
Josh Priebe from Epic here ([email protected]). I work with Apotti and with our Epic standards group.
https://www.hl7.fi/fhir/finnish-base-profiles/1.0-rc2/StructureDefinition-fi-base-condition.html
8.2.1.2 - Diagnosis -based conditions and Finnish käyntisyy
Category=166 is weird, other profiles use a word:
THL Kommentti:
Lääkitystä koskevissa pakollisuuksissa on eroja THL kansallisiin tietomäärityksiin – on tärkeää että tietoa siirrettäessä voidaan ilmaista myös tilanne, jossa esim. ATC-koodi (jota ilmeisesti esimerkissä käytetään ja jota selitetään linkitetyllä sivulla) ei ole saatavissa tai tiedossa. Profiilisivun terminology bindings kohdissa on viittauksia termistöihin / arvojoukkoihin, joiden hyödyntämisestä Suomessa ei ole tietoa – tulisi viitata ainakin niihin koodistoihin / arvojoukkoihin joita Suomessa varmasti hyödynnetään kyseisissä tiedoissa, kuten ATC (miksei ole terminology kohdassa vaikka on ilmeisesti esimerkissä ja lisätietosivulla).
Korjausehdotus: Medication.code pakollisuus pitää poistaa ja selkeyttää profiilin Terminology Bindings kohta siten, että ainakin Suomessa sähköisen reseptin osalta ko. tietoihin käytössä olevat koodistot mainitaan.
Definitely not a high priority, but it might be nice to store artifacts of individual versions into GitHub.
This would allow one to compare version 0.2.0 to version 0.1.0 and see the progress.
Miten näkyy patient resurssissa? Tekstuaalinen kuvaus riittää.
This extension should be replaced by the standard R4 element managingOrganization
If we wanted to be really fancy, we could use the URL (`tel:+358401578947`) as value (see https://hl7.org/fhir/datatypes.html#ContactPoint):
If capturing a phone, fax or similar contact point, the value should be a properly formatted telephone number according to ITU-T E.123 icon. However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, pager, and email addresses are not handled as formal URLs.
And then let it up to clients to format the phone numbers as they see fit.
Originally posted by @mrinnetmaki in #103 (comment)
Register-type-code
Register-specifier
These two elements I'm pretty sure can be handled in the standard FHIR models. I think this could be covered by a link to the register via onBehalfOf
The larger question is probably how to represent a "register" in Finland. Probably extensions in each resource aren't the right way, but maybe a profiled Organization resource can handle this?
Seuraava kommentti enemmän yleisohjeistusta profilointiin ja profiilien käyttöön omissa profiileissa...
Miten ohjeistetaan laajennuksissa olevien tietojen (complex laajennusten, tietotyyppien elementtien) pakollisuudet? Esim. jos laajennus on tietotyypiltään Coding, niin mitä sen elementtejä on käytettävä? System ja code voivat jossain laajennuksessa olla pakko antaa (tultava koodit tietystä koodistosta ja annettava aina koodi). Joskus tietysti on mahdollista, että ei ole tiedossa kuin koodi ei koodistoa tai on tiedossa koodisto mutta ei koodia. Mutta nämä ovat varmaan spesiaalicaseja ja tuollaisen salliminen pitäisi varmaan kuvata pohjaprofiileihin erikseen.
Kuvaus kuinka tämä esitetään pitäisi olla FHIR profiilin tekstuaalisessa kuvauksessa.
Eli kuinka esitetään tapaus, jossa "yhteyshenkilö" ei ole oikeasti ihminen vaan esimerkiksi laitos.
Käytännön käyttötapaus tällaiselle on tilanne, jossa henkilö joka on vanhainkodissa. Jos esim. tarvitsee soittaa vanhainkotiin, niin mistä saadaan tietä mikä vanhainkoti (ja mikä puhelinnumero jne..)?
THL:
Non-disclosure laajennusta käytetään ilmeisesti turvakiellon ilmaisemiseen. Turvakiellon lisäksi olisi hyvä varautua (olisiko mahdollista samalla mekanismilla / kentällä / laajennuksella) jo myös siihen että henkilö pyytää että yhteystietoja ja kotikuntatietoja ei luovuteta muille asianosaisille (julkisuuslain 24 § 1 mom) - ks. esimerkiksi kenttä "Salaiset yhteystiedot" (turvakiellon lisäksi) Sosmeta-palvelun Henkilö-tietokomponentissa.
THL kommentoi:
Osana Patient-profiilia tulisi kuvata, kuinka ilmaistaan kunnan lisäksi asiakkaan hyvinvointialue. Esim. tarvitaanko vastaavaa laajennusta kuin kotikunta tai esim. jos on suunniteltu käytettävän managingOrganization elementtiä - joka tapauksessa asia olisi tarpeen kuvata soveltamisoppaassa. Ei ole suositeltavaa olettaa, että HVA aina pääteltäisiin järjestelmissä esim. kotikunnasta.
Currently profiles are not organized.
We should organize the array before rendering it.
Let's work though all of the issues in the QA report (https://fhir.fi/finnish-base-profiles/qa.html) and fix as much as we can.
One way to clean it up is to just hide the errors. See #94. However, that should never be the first option.
We need to discuss what to do with the examples imported from Kanta PHR. They have quite a few errors. I'm guessing it could be nice to leave some information on these visible in this implementation guide, so implementers could have a way to evaluate how much they should trust any particular example. Any other views?
kommentti: tunnisteista puuttuu Suosikki ja VRK yksilöivä tunniste, jos Terhikki ja SV ovat mukana, niin myös kaksi muuta pitäisi olla
Both of these should be examples in the examples section
perustelu: Profiilissa on edelleen name pakollinen. Tämäkin oli jo kommenttina lausuntokierroskommenteissamme.
korjausehdotus: name pakollisuus pitää poistaa (pakollisuus tulee IPA pohjaprofiilista)
perustelu: laajennukset registerTypeCode ja registerSpecifier ovat nyt Provanance alla, pitäisi olla rekisterinpitäjään kuvaavan Organization resurssin laajennuksia.
korjausehdotus: em. laajennukset pois Provenance profiilista ja siirrettävä Organization profiiliin, johon viitataan Provenancesta (tarvitaan siis Provenancen slaissaus + ehkä jopa rekisterinpitäjä tietoa kuvaava Organization profiilii)
Pystytäänkö tässä profiilissa linjaamaan miten Encounter-resurssilla voi vastata kysymykseen "Mitkä potilaat ovat osastolla X ajankohtana T"?
Encounterin class tulee rajata koodiin IMP (inpatient encounter) - tällöin tieto rajautuu vuodehoitojaksoihin.
Encounterin status tulee rajata koodiin in-progress.
Kutsuva järjestelmä ei aina välttämättä tiedä organisaation sijaintihierarkiaa (vaikka sovelluksella olisikin käytettävissä Location-resurssit, niin sillä ei silti ole välttämättä kaikkea tarvittavaa tietoa siitä mitkä sijainnit ovat minkäkin organisaatioyksikön käytössä). Lisäksi joissakin organisaatioissa sijainteja voidaan käyttää vaihtelevasti eri yksiköiden tarpeisiin (esim. tiettyä huonetta käyttävä yksikkö saattaa muuttua viikonpäivästä riippuen). Kutsuvalle sovellukselle on siten luontevampaa hakea listaus potilaista jotka ovat jonkun tietyn yksikön vastuulla. Perinteisesti potilastietojärjestelmissä wd -tason sijaintia ja organisaatioyksikköä (osastoa) on ymmärretty tarkoittavan samaa asiaa. On kuitenkinn näköpiirissä, että kehitys siirtyy pois perinteisestä osasto=sijainti -mallista (tilojen käyttöä pyritään tehostamaan). Tämä muutos on kuitenkin vasta aluillaan ja siksi "osaston vastuulla olevien potilaiden" hakeminen on edelleen relevantti use case.
Vastuuta kuvaava tietokenttä Encounter-resurssissa on serviceProvider. Encounter spesifikaatio sanoo, että serviceProvider olisi "facility" -tasoinen, tämä voi aiheuttaa tulkintavaikeuksia. Facilityn voi tulkita tarkoittavan yksittäistä kokonaista rakennusta (tai sairaalakompleksia). Tässä ratkaisuehdotuksessa tulkinta viedään tarkemmalle tasolle ja tulkitaan että serviceProvider on se matalimman tason SOTE-palveluyksikkö (osasto), jonka vastuulla potilas on.
Vastuu -kysymys korostuu FHIR:n tapauksessa, jos vertaa sitä, miten vastaava on toteutettu HL7 v2:ssa. HL7 v2:ssa location toimii melko luontevasti, mutta v2:n liipaisu-pohjainen semantiikka ei täysin istu FHIR:n REST-resurssipohjaiseen semantiikkaan, esim. FHIR:ssä location-viittauksen päässä olevan Location resurssin päivittäminen (esim. managingOrganization) aiheuttaisi "yllättäviä" muutoksia encounteriin.
Osaston potilaiden haku onnistuisi FHIR haulla seuraavasti:
GET /Encounter
IMPin-progressgt ja le -rajauksetYllä kuvatulla haulla saadaan kaikki osaston vastuulla olevat potilaat haettua, mutta siihen liittyy muutama lisätulkinta potilaan varsinaisesta sijainnista.
Location elementti statukseltaan active kertoo että potilas on myös fyysisesti paikalla osastolla.
Poikkeuksena yllämainittuun on esimerkiksi teho- ja leikkaus-osasto "vierailut". Nämä vierailut tarkoittavat sitä että osastohoitojakso on tilassa in-progress mutta potilaalla on myös toinen aktiivinen encounter teho- tai toimenpide-yksikössä. Näissä tapauksissa active statuksella oleva location osoittaa location resurssiin jonka mode='kind' (Location). Muut location elementit eivät ole aktiivisiä samanaikaisesti (eli osaston sisäiset lokaatiot kuten vuodepaikka joka voi jäädä reserved tilaan).
Encounterin location elementit:
"location": [
{
"location": {
"reference": "Location/vuoteen-id"
},
"status": "reserved",
"physicalType": "bd",
"period": {
"start": "2001-02-02T12:00:00+02:00"
}
},
{
"location": {
"reference": "Location/teho-id-numero"
},
"status": "active",
"period": {
"start": "2001-02-02T12:10:00+02:00"
}
}
],Teho-osaston Location resurssi:
{
"resourceType": "Location",
"id": "teho-id-numero",
"status": "active",
"name": "TEHO Osasto",
"description": "Potilas on tehohoidossa (kts. erillinen encounter tehokaksosta)",
"mode": "kind",
}https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/
We should list relevant terminologies. At least
Also describe the status of Snomed CT adoption, international codes used in medications, etc...
And think about mentioning future EHDS developments and how they may affect local codings.
https://fhir.fi/finnish-base-profiles/StructureDefinition-register-specifier.html
Vanha huomio kuvaukseen käyttötarkoituksesta:
Tietoa käytetään myös tietojen tietosisällön metatietona kun rekisterinä on työterveyshuolto, ei siis vain Kanta hauissa (tästä kommentoitu jo aiemminkin). Näiden dokumentoinnit löytyy näistä:
Tietysti FHIR maailmaan siirryttäessä kyse ei ole enää MR hauista tai CDA R2:sta, vaan Kanta Potilastiedon arkiston hauista ja tietosisällöistä.
Uusi huomio laajennuksen tietotyypistä:
Laajennuksen RegisterSpecifier tietotyyppinä on string. Sen pitäisi olla Identifier, että voi antaa tarkenteen halutulla tavalla. Alla vaihtoehdot, jotka rekisterin tarkenteessa pitää pystyä antamaan (tämä poimittu Potilastiedon arkiston Medical Records dokumentista):
"_Rekisterintarkenne-kenttä on tyypiltään II ja siinä välitetään työnantajan yksilöintitunnus, joka on muodostettu työnantajan y-tunnuksesta.Tilanteissa, joissa y-tunnusta ei ole olemassa, voidaan käyttää virallista henkilötunnusta tai työterveyspalvelunantajakohtaisesti yksilöivää työnantajan numeroa.
Esimerkki: y-tunnus (root + extension käyttö):
<hl7fi:patientRegistrySpecifier root="1.2.246.10.1234567"/>
tai
<hl7fi:patientRegistrySpecifier extension="123456-7" root="1.2.246.10"/>
Tarkenteen nimi:
hl7fi:patientRegistrySpecifierNameTyönantaja Oy</hl7fi:patientRegistrySpecifierName>
Henkilötunnusta käytettäessä::
<hl7fi:patientRegistrySpecifier extension="010144-123X" root="1.2.246.21"/>
Henkilötunnusta käytettäessä tarkenteen nimenä henkilön nimi:
hl7fi:patientRegistrySpecifierNameMatti Meikäläinen</hl7fi:patientRegistrySpecifierName>
Y-tunnuksettomalle työnantajayritykselle muodostetaan rekisterintarkenne THL:n OID-avaruuteen (537). Solmuluokkaa 30 seuraa työterveyspalvelunantajan yksilöintitunnus (palvelunantajan OID:n yksilöivä osa, esim. y-tunnus ilman väliviivaa) sekä työnantaja-asiakkaan numeerinen yksilöintitunnus palvelunantajan järjestelmässä
<hl7fi:patientRegistrySpecifier root="1.2.246.537.30.2345678.11"/>
Tarkenteen nimi:
hl7fi:patientRegistrySpecifierNameEmployer Ltd</hl7fi:patientRegistrySpecifierName>_"
Jos ja kun tietotyyppiksi muutetaan Identifier, niin pitää huomioida miten edellä kuvatut kolme eri tunnistetta käytännössä tietotyypissä annetaan, varmaan kannattaa antaa aina erikseen systemissä nimiavaruus ja valuessa sitten varsinainen arvo, esim. näin:
Y-tunnus:
system: "1.2.246.10", value: "123456-7"
Henkilötunnus:
system: "1.2.246.21", value: "010144-123X"
Y-tunnukseton työnantajayritys:
system: "1.2.246.537.30", value: "2345678.11"
Rekisterin tarkenteeseen liittyy myös tarkenteen nimi. Se ei ole välttämätön Kanta toiminnallisuuksien näkökulmasta mutta jos tietoa halutaan näyttää käyttöliittymissä, niin vaatii hetun perusteella nimen selvittämisen/y-tunnuksella yrityksen nimen selvittämisen. Y tunnuksemattoman nimeähän ei voi oikein selvittää mitenkään pelkän tunnisteen perusteella. Jos nimi otetaan mukaan -> onko erillinen laajennus vai complex laajennus, jossa tunniste ja nimi erillisinä.
viitataan edelleen jo kumottuun asiakastietolakiin (159/2007).Pitää viitata voimassa olevaan asiakastietolakiin (784/2021)
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.