Rôles des installations
Distinguer les installations, leurs exploitants et leurs rôles de prestation de services.
Utilisez AssetPartyRole pour une assertion, nécessaire indépendamment, indiquant qui possède, exploite
ou entretient des locaux physiques. Gardez l'identité de l'installation distincte de chaque
acteur et de son prestataire institutionnel. Un campus scolaire peut changer d'exploitant
sans devenir un autre campus ; il en va de même pour des locaux agricoles et un
patrimoine immobilier hospitalier.
Il s'agit d'un usage intersectoriel de la relation sur les biens physiques.
School, HealthFacility et AgriculturalFacility conservent leurs sens
distincts. Une Farm est une unité de production économique, et un ProviderSite peut être
virtuel. Aucun des deux ne devient un bien physique du seul fait qu'il a un exploitant ou
une adresse.
Énoncer la responsabilité
L'exemple utilise le référentiel PublicSchema
https://publicschema.org/vocab/asset-role-type pour asset_role_type. Ce référentiel
définit aussi keeper pour un détenteur enregistré.
| Code | Signification | N'établit pas |
|---|---|---|
owner |
L'acteur détient la propriété du bien physique identifié. | Un titre foncier, la propriété du prestataire institutionnel ou l'exploitation de l'installation. |
operator |
L'acteur exploite les locaux identifiés pour leur finalité opérationnelle. | La propriété, l'entretien des locaux, la gouvernance de l'école ou la responsabilité d'exploitant agricole. |
upkeep |
L'acteur est responsable de la mise à disposition et de l'entretien des locaux. | L'identité du prestataire de services ou du propriétaire. |
Utilisez une assertion distincte pour chaque responsabilité, même lorsqu'un acteur en a plusieurs.
Le champ reste ouvert : une source peut conserver son propre référentiel à la place, à condition que ce
référentiel publie ses significations et que son URI accompagne le code. Un mot non qualifié tel que manager ne résout pas ces
distinctions.
asset_actor identifie une personne, une organisation ou un groupe, y compris des
sous-types institutionnels appropriés. Les installations agricoles enregistrent aussi leur exploitant
sous forme d'AssetPartyRole ; ainsi, une pépinière exploitée conjointement peut avoir un
AssetPartyRole daté dont l'acteur est un InformalGroup. Ne requalifiez pas le groupe en
Organization. Un agent logiciel n'est pas un acteur du bien.
Garder les adresses distinctes
AssetAddressAssignment associe un bien physique à une Address pendant une
période. Il utilise subject_uri, assigned_address, address_purpose, start_date
et end_date. L'adresse, la géométrie, la Location géographique nommée et l'installation
physique restent des sujets identifiés séparément.
L'exemple utilise physical et postal du référentiel PublicSchema
https://publicschema.org/vocab/address-purpose. Un changement d'adresse postale n'affirme
pas que l'installation a déménagé. Une position pour l'adresse relève de location de
l'Address ; la forme d'un bâtiment relève de sa spatial_geometry,
avec un encodage et un système de référence de coordonnées explicites. L'école de l'exemple
conserve son adresse physique tandis que sa boîte postale change un mois après le changement
de son exploitant.
La conversion des enregistrements sources d'adresses d'installations nécessite une finalité d'adresse explicitement indiquée pour chaque attribution. Le guide de conversion des dates de relation décrit la correspondance des champs et la conversion des dates. Il ne déduit pas la finalité physique ou postale du texte de l'adresse.
Lire les parcours synthétiques
examples/facility-roles/records.json contient trois historiques de patrimoine immobilier :
| Parcours | Changement | Assertions préservées indépendamment |
|---|---|---|
| Campus scolaire Riverside | Un EducationProvider en remplace un autre comme exploitant des locaux le 1er juillet 2026. Son adresse postale change le 1er août. | Le campus, le propriétaire public, l'organisation chargée de l'entretien et l'adresse physique conservent leurs identités. Un ProviderSite distinct relie la prestation éducative au campus ; un autre ProviderSite est entièrement virtuel. |
| Locaux de séchage et de stockage de céréales | Une Person en remplace une autre comme exploitant de l'entrepôt le 1er mars 2026. L'adresse postale change le 1er avril. | Les locaux conservent leur identité. Une ProducerOrganization a des assertions de propriétaire et d'entretien identifiées séparément. La Farm et la responsabilité de son exploitant agricole restent distinctes. |
| Locaux de l'hôpital Est | L'organisation qui entretient le patrimoine immobilier change le 1er septembre 2026. | La HealthFacility physique, l'exploitant hospitalier institutionnel et le propriétaire public du patrimoine immobilier restent distincts et inchangés. |
Deux enregistrements ServiceCapacityObservation décrivent également 160 places d'apprentissage dotées
en personnel à l'école et 42 lits dotés en personnel à l'hôpital, chacun à un moment d'observation
explicite. Tous deux conservent leur référentiel de mesure local et une QuantityValue avec l'unité UCUM
1. Les observations font référence aux installations physiques identifiées séparément,
et non à leurs organisations prestataires. Ces décomptes datés n'établissent ni disponibilité
actuelle, ni accréditation, ni correspondance avec une ressource FHIR.
L'exemple hospitalier répond à une question intersectorielle de patrimoine immobilier. health/HealthFacility
a une correspondance proche avec Location de FHIR R5, et l'échange médical devrait conserver les
ressources FHIR natives choisies et leurs identités sources.
Location.managingOrganization de FHIR R5 identifie l'organisation responsable
de la mise à disposition et de l'entretien des locaux. C'est une référence unique et optionnelle, sans
période de responsabilité sur cet élément. Un AssetPartyRole daté n'en est donc
pas un substitut exact. Un code d'exploitant ou de propriétaire ne doit pas y être mis en correspondance
sur la seule base de son libellé. Voir la définition de Location dans FHIR R5
et les recommandations d'intégration FHIR.
Les adresses FHIR ont déjà une période d'utilisation. Une assertion d'adresse de bien nécessaire indépendamment n'exige pas de dupliquer un fait d'adresse médical natif, et l'attribution elle-même n'est pas une Address FHIR. Conservez la représentation source choisie et comparez explicitement la sémantique des intervalles avant de projeter des dates. Voir Address.period dans FHIR R5.
Exécuter l'exemple
Depuis la racine du dépôt :
uv run --locked python examples/facility-roles/validate_profile.py
uv run --locked pytest tests/test_facility_roles.py
Le profil de l'exemple exige des URI d'installation et d'acteur résolus localement ainsi qu'un
code de rôle ou de finalité d'adresse déclaré. Il admet les types concrets d'installation, d'acteur
et de groupe énumérés dans validate_profile.py. Des types et des
référentiels sources supplémentaires exigent une décision de profil ; la seule syntaxe d'un URI ne peut pas établir
qu'une cible est une installation physique ou un acteur autorisé. L'exemple utilise des
enregistrements identifiés de premier niveau pour les références et ne récupère pas d'URI distants.
start_date et end_date incluent tous deux leur jour calendaire ; end_date est donc le
dernier jour où la responsabilité est effective. Un rôle antérieur prenant fin le 30 juin et son
remplaçant commençant le 1er juillet ne se chevauchent pas. Une date de fin égale ou postérieure à la date de début
est exigée lorsque les deux dates sont connues. Les dates manquantes restent inconnues, et effective_on renvoie un résultat inconnu
lorsque ces bornes manquantes empêchent une réponse affirmative. Aucune règle d'unicité n'est
imposée aux acteurs ou aux rôles simultanés ; l'exclusivité nécessite une règle applicable de la
source.
Les tests valident les mêmes enregistrements au moyen du JSON Schema généré et du SHACL développé par le contexte, puis appliquent le profil de l'exemple. Ils montrent aussi qu'un URI bien formé pointant vers un site de prestataire virtuel passe le champ d'acteur du bien du vocabulaire, qui a la forme d'un URI, mais échoue à la règle d'acteur du profil, et qu'un groupe peut détenir une responsabilité datée. Les références d'adresse typées ont des vérifications SHACL distinctes. Ce sont des exemples exécutables locaux, et non une application à l'exécution ni une revendication de conformité d'adoptant.
Vous voyez un problème sur cette page ? Signalez-le sur GitHub.
Aidez-nous à améliorer cette page
Surlignez du texte sur cette page pour laisser une annotation. Rejoindre notre groupe de révision pour commencer.
Si vous avez un compte GitHub, cliquez sur l'icône à côté de chaque titre de section pour signaler un problème précis.