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

Clarify the use of basedOn #47

Closed
bdc-ehealth opened this issue Feb 23, 2022 · 4 comments
Closed

Clarify the use of basedOn #47

bdc-ehealth opened this issue Feb 23, 2022 · 4 comments

Comments

@bdc-ehealth
Copy link
Collaborator

comments by @costateixeira
basedOn should only be used (see description in standard) if the ServiceRequest is a request to (partially) fulfill another request (in our case a proposal).

If we want to link a prolongation (order/proposal) to a previous prescription we need an extra extension

@bdc-ehealth bdc-ehealth linked a pull request Feb 23, 2022 that will close this issue
@Mcobbaert
Copy link

Why do we need an extra extension ? Can you please explain ?

@bdc-ehealth
Copy link
Collaborator Author

@Mcobbaert @annenerenhausen It is about semantic interoperability. ServiceRequest.basedOn (http://hl7.org/fhir/R4/servicerequest-definitions.html#ServiceRequest.basedOn) refers to another item that is being fulfilled by this one. It can thus refer to a proposal, careplan, ... . A prolongation of a request does not fulfill the other request, it is an addition to the other request. That is semantically different. Therefore we propose a new extension.

@bdc-ehealth bdc-ehealth added this to Inbox in Development issues via automation Jun 9, 2022
@bdc-ehealth
Copy link
Collaborator Author

WG: "replaces" will be used for prolongations -> see the detailed comments in the standard. "basedOn" will be used in case of a proposal, reference to a Careplan, or any other prior resource that causes this request. "duplicate": is still open.

@bdc-ehealth
Copy link
Collaborator Author

WG: in case of a "duplicate", we don't need the link between the new ServiceRequest and the ServiceRequest it is based on. So we can drop the third option.

Development issues automation moved this from Inbox to Done Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants