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.

Sign up for GitHub

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

Jump to bottom

Update vitals-write.md #43

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update vitals-write.md #43

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8155ca3
Update vitals-write.md
jmandel May 9, 2024
3e2a5e2
Update vitals-write.md
jmandel May 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions input/pagecontent/vitals-write.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ Servers **SHALL** support the submission of Observation resources that _are not_

Servers **MAY** support the submission of Observation resources that _are_ the result of a calculation (such as the "US Core Pediatric BMI for Age Observation Profile") and validate against a [US Core Vital Sign Profile](https://build.fhir.org/ig/HL7/US-Core/profiles-and-extensions.html#observation) that corresponds to a version used by the server for vital sign Observation read requests.

Servers **SHALL** respond to supported and valid vital sign Observation creation requests with a status code of `200 OK` and a content location header, or with a status code of `202 Accepted`. If a content location header is provided, the resources **SHALL** be visible in subsequent read API calls and accessible within the system in the same manner as other patient-submitted data. If a content location header is not provided, and the server does not subsequently make the resource accessible in read API calls, the server **SHALL** have a documented and discoverable reason why it was discarded (e.g., a log entry describing rejection during a review workflow or the applicability of a condition in the "Discarding" section below).
Servers **SHALL** respond to supported and valid vital sign Observation creation requests with a status code of `201 Created` and a `Location` header with a link to the newly created resource. The resources **SHALL** be visible in subsequent read API calls and accessible within the system in the same manner as other patient-submitted data, subject to the system's access control policies, which could potentially prevent a client from immediately reading its writes until some manual review has occurred. If data can be discarded without every becoming visible to the client, the server **SHALL** have a documented policy explaining this behavior and how to obtain documentation of each application of this policy (e.g., a log entry for administrative users describing rejection during a review workflow, or the applicability of a condition in the "Discarding" section below).

Servers **SHALL** support the creation of a single vital sign through a FHIR `create` operation, and **MAY** support the creation of multiple vital signs by submitting a FHIR `Batch` bundle. When batch creation is supported, clients **MAY** use this approach to indicate that a set of Observation resources should be reviewed as a group, and systems **MAY** use this information when sending notifications or displaying the data.

Expand Down Expand Up @@ -207,4 +207,4 @@ Example:
}
}]
}]
```
```