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

Håndtering af RepositoryUniqueId i DocumentReference. #7

Open
tmsMedcom opened this issue Dec 11, 2024 · 0 comments
Open

Håndtering af RepositoryUniqueId i DocumentReference. #7

tmsMedcom opened this issue Dec 11, 2024 · 0 comments

Comments

@tmsMedcom
Copy link
Contributor

Spørgsmål fra KIT:
I dokumentet
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Comprehensive.DocumentReference-mappings.html#mappings-for-xds-and-mhd-mapping-xds
Står der
content - attachment - url >> DocumentEntry.repositoryUniqueId or DocuemntEntry.URI
Altså at respositoryuniqueid og uri begge mapper til til documentreference.url.
Dvs vi skal vælge, hvad valideres for documentreference.url? hvad vil give mest mening at flytte deri fra documententry? Hvordan valideres documentreference.url?

Svar:
Den mapping vi har lagt os op ad er denne: https://hl7.org/fhir/R4/documentreference-mappings.html#xds, som ikke inkluderer DocumentEntry.repositoryUniqueId, formentlig fordi attributten ikke er obligatorisk i den internationale IHE XDS standard. Derfor er det nok heller ikke helt hensigtsmæssig profileret, når jeg tænker mig om, da værdien reelt ikke er inkluderet i mappingen... Jeg opretter lige et issue herom. Eftersom DocumentEntry.repositoryUniqueId er obligatorisk i den danske profilering af IHE XDS-metadata, kunne det give mening, at denne mappes til content - attachment - url. Beskrivelsen af elementet er vist bredt nok at til kunne håndtere begge, eventuelt ved at tillade at 'attachment slices, som kan indeholde hver af de to værdier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant