Open bdc-ehealth opened 3 months ago
If there is any substantive content in the jira issues, we should always ensure it is reflected in the github issue.
The intent is to trace it to the request, not the outcome. Any issues should contain the information of the request, per our rules. I think pointing to jira prevents the visibility we need. (not disagreeing with the result, just looking into the requests that justify the change, which must be open)
On Mon, Aug 12, 2024 at 12:41 PM Bart Decuypere (eHealth) < @.***> wrote:
See the result here: https://build.fhir.org/ig/hl7-be/vaccination/branches/issue-161/Immunization-recorder-logical-reference.json.html
— Reply to this email directly, view it on GitHub https://github.com/hl7-be/vaccination/issues/161#issuecomment-2283630801, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUFHM5AO54BHEIMR6XTZRCGOVAVCNFSM6AAAAABML2LEY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTGYZTAOBQGE . You are receiving this because you commented.Message ID: @.***>
@annenerenhausen @costateixeira @bdc-ehealth Do we need a general approach for all caresets for the recorder? Taking into account patient viewers as cozo, mijngezondheid,...Is a logical reference sufficient? Can we expect them to connect with the authentic sources to add necessary information about the recorder?
It is in some way similar to the issue about the translations/labels.
To discuss during the core workgroups and not blocking for publication.
see: https://be-ehealth-standards.atlassian.net/jira/servicedesk/projects/ESI/queues/custom/20/ESI-839