Vissue-MM-3277:Identification - Bewerkingsoverzicht

Ahenket: MM-3277 Add link

2022-05-23T11:19:17Z

MM-3277 Add link

← Oudere versie		Versie van 23 mei 2022 11:19
Regel 101:		Regel 101:
	Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ ([https://www.ietf.org/rfc/rfc4122.txt RfC4122]) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.		Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ ([https://www.ietf.org/rfc/rfc4122.txt RfC4122]) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.

	~~The basic rule is that systems~~ SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:		Systems - as stated in [[#ID-4]] - SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:

	* FHIR Identifier.system SHALL be of type Object IDentifier (OID), unless a formal 1-to-1 mapping exists between a URL based system and the OID. In this case and only in this case, the system SHALL be the URL		* FHIR Identifier.system SHALL be of type Object IDentifier (OID), unless a formal 1-to-1 mapping exists between a URL based system and the OID. In this case and only in this case, the system SHALL be the URL

Ahenket: MM-3277 Fix typo

2022-05-23T11:17:27Z

MM-3277 Fix typo

← Oudere versie		Versie van 23 mei 2022 11:17
Regel 43:		Regel 43:
	</div>		</div>

	{{IssueBox: TODO ''SHALL have a methodology'' Does this need elaboration in normative or informative sense?}}		{{IssueBox\|TODO ''SHALL have a methodology'' Does this need elaboration in normative or informative sense?}}

	{{NoteBox\|Methodologies for guaranteeing global uniqueness, or at least reasonable levels thereof include:		{{NoteBox\|Methodologies for guaranteeing global uniqueness, or at least reasonable levels thereof include:

Ahenket: MM-3277 Add TODOs

2022-05-23T11:15:53Z

MM-3277 Add TODOs

← Oudere versie		Versie van 23 mei 2022 11:15
Regel 42:		Regel 42:
	<div id="ID-4">'''ID-4''' Any system regardless of being the source SHALL maintain persistent logical ids when required for the use cases for the information and unique within that system</div>		<div id="ID-4">'''ID-4''' Any system regardless of being the source SHALL maintain persistent logical ids when required for the use cases for the information and unique within that system</div>
	</div>		</div>

			{{IssueBox: TODO ''SHALL have a methodology'' Does this need elaboration in normative or informative sense?}}

	{{NoteBox\|Methodologies for guaranteeing global uniqueness, or at least reasonable levels thereof include:		{{NoteBox\|Methodologies for guaranteeing global uniqueness, or at least reasonable levels thereof include:

Ahenket: MM-3277 Add TODOs

2022-05-23T11:11:33Z

MM-3277 Add TODOs

← Oudere versie		Versie van 23 mei 2022 11:11
Regel 18:		Regel 18:
	* The same action could be billed multiple times		* The same action could be billed multiple times

	{{~~NoteBox~~\|TODO: Potential linking opportunity with risk assessment models like [https://www.patientsafety.va.gov/professionals/onthejob/hfmea.asp HFMEA]}}		{{IssueBox\|TODO: Potential linking opportunity with risk assessment models like [https://www.patientsafety.va.gov/professionals/onthejob/hfmea.asp HFMEA]}}

	There are a lot of information objects that are typically identified: observations, images, documents, problems, practitioners, and organizations. The list is not a closed list however, and at time of writing it does not exist as normative list. Over time new information objects will be defined and added to the list of identifiable information objects.		There are a lot of information objects that are typically identified: observations, images, documents, problems, practitioners, and organizations. The list is not a closed list however, and at time of writing it does not exist as normative list. Over time new information objects will be defined and added to the list of identifiable information objects.

	{{~~NoteBox~~\|TODO: How/What/Where/When is this list being maintained. It now lives in expectation which is not a solid basis.}}		{{IssueBox\|TODO: How/What/Where/When is this list being maintained. It now lives in expectation which is not a solid basis.}}

	While ‘information’ should have persistent identifiers, also known as business identifiers, there are usually also other ids at play of a more technical or temporal nature. They include message ids on Edifact and HL7 V3 interactions, FHIR Resource.id supporting RESTful communication and more. These temporal ids are a source of confusion because of their overlapping name and sometimes seemingly overlapping function.		While ‘information’ should have persistent identifiers, also known as business identifiers, there are usually also other ids at play of a more technical or temporal nature. They include message ids on Edifact and HL7 V3 interactions, FHIR Resource.id supporting RESTful communication and more. These temporal ids are a source of confusion because of their overlapping name and sometimes seemingly overlapping function.
Regel 150:		Regel 150:
	==Assignment method for locally defined OIDs==		==Assignment method for locally defined OIDs==

	{{~~NoteBox~~\|TODO ... this is still Dutch and a copy of page 28 of 177 Implementatiehandleiding HL7v3 Basiscomponenten versie 2.3-Rev2 which is also available online. Consider translation of simply referring instead of duplicating}}		{{IssueBox\|TODO ... this is still Dutch and a copy of page 28 of 177 Implementatiehandleiding HL7v3 Basiscomponenten versie 2.3-Rev2 which is also available online. Consider translation of simply referring instead of duplicating}}

	Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.		Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.

Ahenket: MM-3277 Add TODOs

2022-05-23T11:07:46Z

MM-3277 Add TODOs

← Oudere versie		Versie van 23 mei 2022 11:07
Regel 17:		Regel 17:
	* System could proliferate duplicate information to other systems		* System could proliferate duplicate information to other systems
	* The same action could be billed multiple times		* The same action could be billed multiple times

			{{NoteBox\|TODO: Potential linking opportunity with risk assessment models like [https://www.patientsafety.va.gov/professionals/onthejob/hfmea.asp HFMEA]}}

	There are a lot of information objects that are typically identified: observations, images, documents, problems, practitioners, and organizations. The list is not a closed list however, and at time of writing it does not exist as normative list. Over time new information objects will be defined and added to the list of identifiable information objects.		There are a lot of information objects that are typically identified: observations, images, documents, problems, practitioners, and organizations. The list is not a closed list however, and at time of writing it does not exist as normative list. Over time new information objects will be defined and added to the list of identifiable information objects.

			{{NoteBox\|TODO: How/What/Where/When is this list being maintained. It now lives in expectation which is not a solid basis.}}

	While ‘information’ should have persistent identifiers, also known as business identifiers, there are usually also other ids at play of a more technical or temporal nature. They include message ids on Edifact and HL7 V3 interactions, FHIR Resource.id supporting RESTful communication and more. These temporal ids are a source of confusion because of their overlapping name and sometimes seemingly overlapping function.		While ‘information’ should have persistent identifiers, also known as business identifiers, there are usually also other ids at play of a more technical or temporal nature. They include message ids on Edifact and HL7 V3 interactions, FHIR Resource.id supporting RESTful communication and more. These temporal ids are a source of confusion because of their overlapping name and sometimes seemingly overlapping function.

Ahenket: MM-3277 Add link

2022-05-23T11:02:19Z

MM-3277 Add link

← Oudere versie		Versie van 23 mei 2022 11:02
Regel 93:		Regel 93:
	If only one identifier exists on a resource without Identifier.use, it SHALL be the primary identifier of that resource as assigned by the source. If multiple identifiers exist, then Identifier.use SHALL be the discriminator (usual \| official \| temp \| secondary \| old).		If only one identifier exists on a resource without Identifier.use, it SHALL be the primary identifier of that resource as assigned by the source. If multiple identifiers exist, then Identifier.use SHALL be the discriminator (usual \| official \| temp \| secondary \| old).

	Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ (RfC4122) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.		Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ ([https://www.ietf.org/rfc/rfc4122.txt RfC4122]) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.

	The basic rule is that systems SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:		The basic rule is that systems SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:

Ahenket: MM-3277 Fix typo

2022-05-23T11:01:34Z

MM-3277 Fix typo

← Oudere versie		Versie van 23 mei 2022 11:01
Regel 93:		Regel 93:
	If only one identifier exists on a resource without Identifier.use, it SHALL be the primary identifier of that resource as assigned by the source. If multiple identifiers exist, then Identifier.use SHALL be the discriminator (usual \| official \| temp \| secondary \| old).		If only one identifier exists on a resource without Identifier.use, it SHALL be the primary identifier of that resource as assigned by the source. If multiple identifiers exist, then Identifier.use SHALL be the discriminator (usual \| official \| temp \| secondary \| old).

	Business identifiers always of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ (RfC4122) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.		Business identifiers always consist of the identifier itself and the identification system that produced it. The identifier SHALL be unique within the identification system. The identifier is considered case sensitive unless the identification system is known to be case insensitive. This is specifically relevant for uuids which are lower case ‘on output’ (RfC4122) but case insensitive ‘on input’. While HL7 V3 did not enforce any casing on uuids, the expectation in FHIR is a lower-case representation because communication is considered ‘on output’. This could mean that a simple string comparison could fail based on casing.

	The basic rule is that systems SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:		The basic rule is that systems SHALL preserve the original business identifier. Some implementation aspects have to be taken into account. Most of current information exchanges are based on something other than FHIR. Most of the cross enterprise/realm exchanges are based on HL7 V3/CDA as touched upon above for uuids. All HL7 V3 identifiers can be converted into FHIR. Some FHIR identifiers cannot be converted into HL7 V3 at all. Hence additional requirements apply for identifiers to flow safely across domains and technical implementations:

Ahenket: MM-3277 Add note on TODO

2022-05-23T10:59:52Z

MM-3277 Add note on TODO

Ahenket: MM-3277 More markup applied

2022-05-23T10:55:53Z

MM-3277 More markup applied

← Oudere versie		Versie van 23 mei 2022 10:55
Regel 109:		Regel 109:
	* [https://bits.nictiz.nl/browse/MM-2829 MM-2829] "Hoe om te gaan met FHIR identifiers en Gegevensdienst en MedMij releases?"		* [https://bits.nictiz.nl/browse/MM-2829 MM-2829] "Hoe om te gaan met FHIR identifiers en Gegevensdienst en MedMij releases?"
	* [https://bits.nictiz.nl/browse/MM-2832 MM-2832] "Verplicht stellen van Resource.identifier bij ingestuurde zelfmetingen"		* [https://bits.nictiz.nl/browse/MM-2832 MM-2832] "Verplicht stellen van Resource.identifier bij ingestuurde zelfmetingen"
	* [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Resource.2Eid.20and.20endpoint.20STU3.2FR4] FHIR Chat "Resource.id and endpoint STU3/R4"		* [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Resource.2Eid.20and.20endpoint.20STU3.2FR4 FHIR Chat "Resource.id and endpoint STU3/R4"]
	* [[BgZ:V1.0_BgZ_MSZ_Informatiestandaard\|Informatiestandaard Basisgegevensset Zorg Medisch Specialistische Zorg (BgZ MSZ)]]		* [[BgZ:V1.0_BgZ_MSZ_Informatiestandaard\|Informatiestandaard Basisgegevensset Zorg Medisch Specialistische Zorg (BgZ MSZ)]]
	* [http://hl7.org/fhir/resource.html#identifiers FHIR Resource identifiers]		* [http://hl7.org/fhir/resource.html#identifiers FHIR Resource identifiers]

Ahenket: MM-3277 More markup applied

2022-05-23T10:55:13Z

MM-3277 More markup applied

← Oudere versie		Versie van 23 mei 2022 10:55
Regel 110:		Regel 110:
	* [https://bits.nictiz.nl/browse/MM-2832 MM-2832] "Verplicht stellen van Resource.identifier bij ingestuurde zelfmetingen"		* [https://bits.nictiz.nl/browse/MM-2832 MM-2832] "Verplicht stellen van Resource.identifier bij ingestuurde zelfmetingen"
	* [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Resource.2Eid.20and.20endpoint.20STU3.2FR4] FHIR Chat "Resource.id and endpoint STU3/R4"		* [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Resource.2Eid.20and.20endpoint.20STU3.2FR4] FHIR Chat "Resource.id and endpoint STU3/R4"
	* [BgZ:V1.0_BgZ_MSZ_Informatiestandaard] Informatiestandaard Basisgegevensset Zorg Medisch Specialistische Zorg (BgZ MSZ)		* [[BgZ:V1.0_BgZ_MSZ_Informatiestandaard\|Informatiestandaard Basisgegevensset Zorg Medisch Specialistische Zorg (BgZ MSZ)]]
	* [http://hl7.org/fhir/resource.html#identifiers FHIR Resource identifiers]		* [http://hl7.org/fhir/resource.html#identifiers FHIR Resource identifiers]
	* [https://www.hl7.nl/wiki/index.php?title=DatatypesR1:II HL7 NL Datatype Instance Identifier (II)]		* [https://www.hl7.nl/wiki/index.php?title=DatatypesR1:II HL7 NL Datatype Instance Identifier (II)]

← Oudere versie		Versie van 23 mei 2022 10:59
Regel 145:		Regel 145:

	==Assignment method for locally defined OIDs==		==Assignment method for locally defined OIDs==

			{{NoteBox\|TODO ... this is still Dutch and a copy of page 28 of 177 Implementatiehandleiding HL7v3 Basiscomponenten versie 2.3-Rev2 which is also available online. Consider translation of simply referring instead of duplicating}}

	Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.		Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.
Regel 156:		Regel 158:

	De volgende IDs kunnen in principe als root dienen in de zorg:		De volgende IDs kunnen in principe als root dienen in de zorg:
	* De applicatie, o.b.v. de door het LSP uitgedeelde applicatie ID (dit zou handig zijn, maar er is dan geen vanzelfsprekende assigning authority).		* De '''applicatie''', o.b.v. de door het LSP uitgedeelde applicatie ID (dit zou handig zijn, maar er is dan geen vanzelfsprekende assigning authority).
	* De zorgaanbieder, o.b.v. het UZI Register Abonnee (URA) nummer (probleem is dat nog niet zeker is of URA 1-op-1 bij zorgaanbieder zal horen).		* De '''zorgaanbieder''', o.b.v. het UZI Register Abonnee (URA) nummer (probleem is dat nog niet zeker is of URA 1-op-1 bij zorgaanbieder zal horen).
	* Het Goed Beheerd Zorgsysteem, o.b.v. de daaraan uitgedeelde GBZ ID (probleem is dat de juridische definitie van een GBZ nog niet 100% zeker is).		* Het '''Goed Beheerd Zorgsysteem''', o.b.v. de daaraan uitgedeelde GBZ ID (probleem is dat de juridische definitie van een GBZ nog niet 100% zeker is).
	* De IT leverancier, o.b.v. een nog te bepalen identificatie van de organisatie (het lijkt niet zo handig om leverancier assigning authority te maken, bijvoorbeeld i.v.m. conversie naar een andere leverancier). ~~28 van 177 Implementatiehandleiding HL7v3 Basiscomponenten versie 2.3-Rev2~~		* De '''IT-leverancier''', o.b.v. een nog te bepalen identificatie van de organisatie (het lijkt niet zo handig om leverancier assigning authority te maken, bijvoorbeeld i.v.m. conversie naar een andere leverancier).

	Implementatierichtlijnen zijn nodig om duidelijk te maken welke OID structuur gebruikt moet worden in HL7 versie 3 berichten binnen AORTA.		Implementatierichtlijnen zijn nodig om duidelijk te maken welke OID-structuur gebruikt moet worden in HL7 versie 3 berichten binnen AORTA.

	Ten behoeve van de wereldwijde uniciteit en persistentie van gegevens-identificatie wordt de zorgaanbieder geadviseerd haar URA (UZI Register Abonneenummer) te gebruiken als basis voor de OID root van alle binnen de zorgaanbieder gegenereerde gegevens. Zorgaanbieders die reeds een bestaande OID hanteren, mogen deze blijven gebruiken. Voor goed OID-gebruik moeten de volgende zaken worden meegenomen:		'''Ten behoeve van de wereldwijde uniciteit en persistentie van gegevens-identificatie wordt de zorgaanbieder geadviseerd haar URA (UZI Register Abonneenummer) te gebruiken als basis voor de OID root van alle binnen de zorgaanbieder gegenereerde gegevens. Zorgaanbieders die reeds een bestaande OID hanteren, mogen deze blijven gebruiken.''' Voor goed OID-gebruik moeten de volgende zaken worden meegenomen:
	* De inrichting van identificatie is een samenspel tussen zorgaanbieder en systeemleverancier		* De inrichting van identificatie is een samenspel tussen zorgaanbieder en systeemleverancier
	* Identificatie dient persistent en wereldwijd uniek te zijn		* Identificatie dient persistent en wereldwijd uniek te zijn
Regel 170:		Regel 172:
	* Voorbeeld voor zorgaanbieder met URA 12345678 die deze voor identificatie in zijn lab- en radiologiesysteem wil gebruiken LAB: 2.16.528.1.1007.3.3.12345678.1 RAD: 2.16.528.1.1007.3.3.12345678.2		* Voorbeeld voor zorgaanbieder met URA 12345678 die deze voor identificatie in zijn lab- en radiologiesysteem wil gebruiken LAB: 2.16.528.1.1007.3.3.12345678.1 RAD: 2.16.528.1.1007.3.3.12345678.2
	* Identificatie op basis van URA werkt alleen goed als de zorgaanbieder administratie over toegekende OID's per systeem bijhoudt, zodat er geen ambiguïteit ontstaat		* Identificatie op basis van URA werkt alleen goed als de zorgaanbieder administratie over toegekende OID's per systeem bijhoudt, zodat er geen ambiguïteit ontstaat
	* Als een zorgaanbieder geen OID-administratie per systeem kan of wil voeren, dan kan een leverancier deze service voor zijn systeem bieden door een OID aan te vragen. Op basis hiervan kan de leverancier, branches toekennen aan klanten. Uiteraard dient de leverancier dan de administratie hierop bij te houden.		* Als een zorgaanbieder geen OID-administratie per systeem kan of wil voeren, dan kan een leverancier deze service voor zijn systeem bieden door een OID aan te vragen. Op basis hiervan kan de leverancier, branches toekennen aan klanten. Uiteraard dient de leverancier dan de administratie hierop bij te houden.

	==OID-related business rules for applications==		==OID-related business rules for applications==