Add Device, Healthcare Service and Resource Request docs for 3.1 - #80
Conversation
Publish the Device and Healthcare Service concepts and their flows, and a new Resource Request concept with five flows, from the care_docs sources. All three sit as module categories under Flows > Facility.
Deploying coredocs with
|
| Latest commit: |
82db967
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9d8e5754.coredocs.pages.dev |
| Branch Preview URL: | https://docs-facility-device-service.coredocs.pages.dev |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Care docs review — PR #80
The three modules are in good shape overall: pages follow the concept and flow templates, sections are named and ordered correctly, there is no corruption, no {#...} heading ids or bare braces, slugs are kebab-case with verb-phrase flow slugs, and permission names are used in display form. I verified Can Manage Devices on Facility and Can Create Healthcare Service on Facility against care/security/permissions/, and the P print shortcut against care_fe/src/config/keyboardShortcuts.json — all correct. The flow sidebar (checklist 10) was correctly updated for all fifteen new flows.
Main findings
- Mirroring (checklist 11) — the change lands only in
version-3.1. The conventions require 3.0 and 3.1 to be byte-identical;versioned_docs/version-3.0/**andversioned_sidebars/version-3.0-sidebars.jsonwere not updated. This is the largest item. - FHIR narration (checklist 7) —
healthcare-service.mdxsays "is similar in structure to the FHIR HealthcareService resource". The link alone is enough. - Missing Reference links — both rewritten concepts dropped the
Reference:line, and the new resource-request concept never adds one, even thoughreferences/facility/device.mdx,references/facility/healthcare-service.mdxandreferences/platform/resource-request.mdxall exist. - Style consistency — the healthcare-service and resource-request flows do not bold UI labels, while the device flows do.
Corrections to two of my own inline comments
On re-checking, ../../concepts/facility/location.mdx from concepts/facility/ is wrong as I described, but only because it is redundant — Docusaurus resolves .mdx links file-relative, so it climbs to versioned_docs/version-3.1/ and back down, which does resolve. Please treat those two comments as a style preference (../facility/location.mdx), not a build breaker. The patient link in resource-request.mdx is the one to check carefully, since extensionless translated-doc links are the fragile case.
Could not verify
- Whether the resource-request viewset genuinely has no permission gating, as the concept states.
- Exact toast strings ("Device registered successfully", "Healthcare service created successfully"), the
Fill My Detailscontrol, and the Active/Completed status grouping — please confirm againstcare_fepublic/locale/en.json. - Whether
references/platform/resource-request.mdxshould move to thefacilitydomain, as the description raises. Worth a decision, but out of scope for this review.
Non-blocking.> Generated by Docs Reviewer for #80 · opus50 · 141.1 AIC · ⌖ 17.2 AIC · ⊞ 11K
| ## Definition | ||
|
|
||
| ## What it represents | ||
| A **healthcare service** in Care is a service that a facility offers. A pharmacy counter, a lab, and a scheduling desk are healthcare services. Care's healthcare service is similar in structure to the FHIR [HealthcareService](https://build.fhir.org/healthcareservice.html) resource. |
There was a problem hiding this comment.
Checklist item 7 (FHIR): link the FHIR resource page, but do not narrate the mapping. Drop the second sentence and link on first mention instead: A **[healthcare service]((build.fhir.org/redacted) in Care is a service that a facility offers.
| - Flow: [Update a resource request's status](../../flows/facility/resource-request/update-resource-request-status.mdx) | ||
| - Flow: [Comment on a resource request](../../flows/facility/resource-request/comment-resource-request.mdx) | ||
| - Flow: [Print a resource request letter](../../flows/facility/resource-request/print-resource-request-letter.mdx) | ||
| - Concept: [Patient](../../concepts/clinical/patient) |
There was a problem hiding this comment.
Broken-link risk: the conventions say extensionless links are used only for the translated docs, and then relative to the file — ../../concepts/clinical/patient resolves outside concepts/. From concepts/facility/ this should be ../clinical/patient (no extension, since patient is translated).
| - Flow: [Record a device's service history](../../flows/facility/device/device-service-history.mdx) | ||
| - Flow: [Delete a device](../../flows/facility/device/delete-device.mdx) | ||
| - Concept: [Department](../../concepts/facility/department.mdx) | ||
| - Concept: [Locations](../../concepts/facility/location.mdx) |
There was a problem hiding this comment.
Same relative-path issue: from concepts/facility/, links to sibling concepts must be ../facility/location.mdx / ../facility/department.mdx (or ./location.mdx), not ../../concepts/facility/.... ../../concepts/... climbs out of versioned_docs/version-3.1/concepts and will not resolve. Applies to the Department link on the next line too.
| - Flow: [Edit a healthcare service](../../flows/facility/healthcare-service/edit-healthcare-service.mdx) | ||
| - Flow: [Delete a healthcare service](../../flows/facility/healthcare-service/delete-healthcare-service.mdx) | ||
| - Concept: [Locations](../../concepts/facility/location.mdx) | ||
| - Concept: [Department](../../concepts/facility/department.mdx) |
There was a problem hiding this comment.
Same as in device.mdx: use ../facility/department.mdx and ../facility/location.mdx here rather than ../../concepts/facility/..., per the link rule in .claude/skills/care-concept-doc/references/conventions.md.
| }, | ||
| { | ||
| "type": "category", | ||
| "label": "Device", |
There was a problem hiding this comment.
Mirroring (checklist 11): this pull request touches only version-3.1. The conventions require versioned_docs/version-3.0 and version-3.1 to stay byte-identical, so the same 21 files and the matching versioned_sidebars/version-3.0-sidebars.json entries are missing. If 3.0 is intentionally frozen for these modules, please say so in the description.
| | Can Manage Devices on Facility | Create, edit, and delete a device. Link a device to a location or a department. Add or edit the service history of a device. The Staff, Admin, Facility Admin, and Pharmacist roles hold this permission. | | ||
| | Can Manage Device Associations to Encounters | Link a device to an encounter, or unlink it. You do this from the encounter. The Staff, Admin, Doctor, Nurse, and Facility Admin roles hold this permission. | | ||
|
|
||
| ## Related |
There was a problem hiding this comment.
The old page linked Reference: [Device (technical)](../../references/facility/device.mdx), and that file still exists. The concept template lists a Reference line in Related — please restore it here and in healthcare-service.mdx (../../references/facility/healthcare-service.mdx).
|
|
||
| Note: Care does not enforce an order for these statuses. Any user who can update the request can set any status at any time. Care has no separate Approve, Reject, or Cancel actions. There is only one status choice. | ||
|
|
||
| ## Permissions |
There was a problem hiding this comment.
A reference already exists at references/platform/resource-request.mdx; add it as a Reference: line in Related. Also worth noting: the Permissions section here is prose only. That is allowed by the skill when a resource has no permission gating, but please confirm the resource-request viewset really performs no AuthorizationController check, since the claim is strong.
| ## Types | ||
|
|
||
| A device can carry an optional **type** that connects it to a registered plugin for behaviour beyond plain inventory tracking — the bundled example is a `camera`. The type is chosen at creation and cannot change afterward; deployments register their own through the device-type registry. A device with no type is still fully tracked; it simply has no specialised behaviour attached. | ||
| - Available. The device is not lost, not damaged, and not destroyed. |
There was a problem hiding this comment.
Inconsistent list: the first bullet carries a definition and the other three are bare labels. Use the same | Status | Description | table shape as the Status section above, per the concept template.
|
|
||
| ### 1. Open the healthcare services list | ||
|
|
||
| Open the facility. Select Settings. Select Healthcare Services. |
There was a problem hiding this comment.
UI labels are not emphasised in this file, while the device flows bold them (Select **Settings**). Terminology/consistency (checklist 14): please bold the UI labels throughout the healthcare-service flows to match.
1 participant
What
Publishes the Device, Healthcare Service and Resource Request documentation from
care_docsinto the docs site (version 3.1).Device
concepts/facility/device.mdxwith the authored versionflows/facility/device/: create, view, edit, link to a location and department, record service history, deleteHealthcare Service
concepts/facility/healthcare-service.mdxwith the authored versionflows/facility/healthcare-service/: create, view, edit, deleteResource Request
concepts/facility/resource-request.mdxflows/facility/resource-request/: create, view, update status, comment, print letterAll three sit as module categories under
Flows > Facility.Stacked on #78
This branches off
docs/facility-department-location(#78), because the Device, Healthcare Service and Resource Request docs all link to the Department concept that #78 introduces. GitHub retargets this PR tomainonce #78 merges.Notes for reviewers
references/platform/resource-request.mdx, under the platform domain rather than facility; worth deciding whether the two should sit in the same domain.Verification
Docusaurus build passes for both
enandmllocales.