-
Notifications
You must be signed in to change notification settings - Fork 4
Add Device, Healthcare Service and Resource Request docs for 3.1 #80
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,71 +4,80 @@ sidebar_position: 6 | |
|
|
||
| # Device | ||
|
|
||
| A **device** in Care is a piece of equipment a facility owns and tracks — a ventilator, an infusion pump, a monitor, a camera. The record is the platform's durable answer to three questions: what equipment exists, where it sits right now, and which patient encounter it is supporting. | ||
| ## Definition | ||
|
|
||
| ## What it represents | ||
| A **[device](https://build.fhir.org/device.html)** in Care is a piece of equipment that a facility owns or uses, for example a ventilator or a monitor. Care tracks where a device is, which department manages it, its status, and its maintenance history. | ||
|
|
||
| In Care's FHIR-aligned model, a device maps to the **Device** resource. It holds the things you'd find on an asset register — names and identifiers, manufacturer and model, serial and lot numbers, manufacture and expiry dates — alongside the live picture of where the device is and what it is doing. | ||
| ## Key Attributes | ||
|
|
||
| A device is the instrument, not a reading from it. The values a monitor produces are stored as observations on an encounter; the device record tracks the instrument itself across every location and patient it touches over its working life. One device, many encounters — the record is what keeps that history coherent. | ||
| | Components | What it captures | | ||
| | --- | --- | | ||
| | Registered Name | The name Care uses to identify the device. This is required. | | ||
| | User Friendly Name | A more familiar name for the device. This is optional. | | ||
| | Identifier | An identifier for the device, for example an inventory tag. This is optional. | | ||
| | Manufacturer | The maker of the device. This is optional. | | ||
| | Manufacture Date | When the device was made. This cannot be a future date. This is optional. | | ||
| | Expiration Date | When the device expires. This must be after the manufacture date. This is optional. | | ||
| | Lot Number | The lot number of the device. This is optional. | | ||
| | Serial Number | The serial number of the device. This is optional. | | ||
| | Model Number | The model number of the device. This is optional. | | ||
| | Part Number | The part number of the device. This is optional. | | ||
| | Contact Points | Phone numbers, emails, or other contact details for the device, for example a vendor support line. This is optional. | | ||
| | Status | Whether the device is Active, Inactive, or Entered in Error. | | ||
| | Availability Status | Whether the device is Available, Lost, Damaged, or Destroyed. | | ||
| | Location | The location that currently holds the device. | | ||
| | Managing Organization | The department that is responsible for the device. | | ||
|
|
||
| ## Status | ||
| ### Contact Points | ||
|
|
||
| A device carries two status dimensions that move independently, so it can be in service yet temporarily out of action. | ||
| Each contact point has a type and a value. Care offers these types: | ||
|
|
||
| **Operational status** says whether the device is in service: | ||
| - Phone | ||
| - Fax | ||
| - SMS | ||
| - URL | ||
| - Pager | ||
| - Other | ||
|
|
||
| - **Active** — in service and usable | ||
| - **Inactive** — not currently in service | ||
| - **Entered in error** — the record was created by mistake and should be disregarded | ||
| ### Location and Managing Organization | ||
|
|
||
| **Availability status** describes its physical condition: | ||
| You do not set the location or the managing organization on the create form or the edit form. You set them separately. See the [Link a device to a location and a department](../../flows/facility/device/link-device-location-department.mdx) flow. | ||
|
|
||
| - **Available** — can be located and used | ||
| - **Lost** — cannot be found | ||
| - **Damaged** — needs repair before use | ||
| - **Destroyed** — no longer usable | ||
| Note: Care keeps a history of every location that the device has been in. You see this history when you associate or change the location. Care also keeps a history of the encounters that used the device. You see this history when you select **View History** next to the **Encounter** row. You link a device to an encounter from the **Devices** tab of the encounter, not from the page of the device. | ||
|
|
||
| Keeping these separate means a working device that has gone missing reads as *active but lost* — accurate, rather than forcing a single status to mean two things. | ||
| ### Status | ||
|
|
||
| ## How it connects | ||
| | Status | Description | | ||
| | --- | --- | | ||
| | Active | The device is in active use. | | ||
| | Inactive | The device is not in active use. | | ||
| | Entered in Error | Someone added the device by mistake. | | ||
|
|
||
| A device moves through a facility, and Care records that journey as history rather than overwriting it: | ||
| ### Availability Status | ||
|
|
||
| - **Facility** — every device belongs to exactly one owning facility, set from context rather than chosen on each edit. | ||
| - **Managing organization** — the team accountable for the device. This also decides who can see and manage it, through the organization hierarchy. | ||
| - **Current location** — where the device sits today. Moving it closes the old placement and opens a new one, leaving an auditable trail of everywhere it has been. | ||
| - **Current encounter** — the patient encounter the device is actively supporting. Attaching and detaching follow the same close-then-open pattern; when an encounter is completed, its devices are released automatically. | ||
| Availability Status records the physical condition of the device. Care offers these values: | ||
|
|
||
| Because placements and encounter links are kept as history, you can always answer "where was this last week?" or "which patients did it serve?" — not just where it is now. | ||
|
|
||
| ## 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. | ||
| - Lost | ||
| - Damaged | ||
| - Destroyed | ||
|
|
||
| ## Permissions | ||
|
|
||
| Access to devices is governed by facility-scoped permissions. | ||
|
|
||
| | Permission | Description | System Roles | | ||
| | --- | --- | --- | | ||
| | `can_manage_devices` | Create devices, and update, delete, relocate, service, or change the managing organization of existing ones | Staff, Admin, Facility Admin, Pharmacist | | ||
| | `can_list_devices` | View devices registered to a facility and their location, encounter, and service history | Staff, Admin, Doctor, Nurse, Facility Admin, Pharmacist | | ||
| | `can_manage_device_associations_to_encounters` | Attach a device to or detach it from a patient encounter | Staff, Admin, Doctor, Nurse, Facility Admin | | ||
| | `can_write_encounter` | Also required on the target encounter when attaching a device to it | Admin, Doctor, Nurse, Facility Admin | | ||
| | `can_write_facility_locations` | Also required on the target location when placing a device there | Facility Admin, Admin, Staff | | ||
| | `can_manage_facility_organization` | Also required on the organization when setting or clearing a device's managing organization | Facility Admin, Administrator | | ||
|
|
||
| Roles are granted through facility and organization memberships, and they cascade down the organization tree — a user's access to a device follows from the managing organization it sits under. | ||
| | Permission | What it allows | | ||
| | --- | --- | | ||
| | Can List Devices on Facility | View devices and their details. The Staff, Admin, Doctor, Nurse, Facility Admin, and Pharmacist roles hold this permission. | | ||
| | 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The old page linked |
||
|
|
||
| - Reference: [Device (technical)](../../references/facility/device.mdx) | ||
| - Concept: [Facility](../facility/facility.mdx) | ||
| - Concept: [Location](../facility/location.mdx) | ||
| - Concept: [Encounter](../clinical/encounter.mdx) | ||
| - Concept: [Organization](../access-governance/organization.mdx) | ||
|
|
||
| ## FHIR reference | ||
|
|
||
| Care's device aligns with the FHIR **Device** resource, which represents a manufactured item used in delivering healthcare. Care extends it with location and encounter history so equipment can be traced across its working life. | ||
| - Flow: [Create a device](../../flows/facility/device/create-device.mdx) | ||
| - Flow: [View devices and a device's details](../../flows/facility/device/view-devices.mdx) | ||
| - Flow: [Edit a device](../../flows/facility/device/edit-device.mdx) | ||
| - Flow: [Link a device to a location and a department](../../flows/facility/device/link-device-location-department.mdx) | ||
| - 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) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same relative-path issue: from |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,53 +4,39 @@ sidebar_position: 5 | |
|
|
||
| # Healthcare Service | ||
|
|
||
| A **healthcare service** is a named offering that a facility provides — cardiology, a laboratory, radiology, a pharmacy, an outpatient clinic. It is the "what we offer" catalog entry: the thing patients book into, the thing schedules attach to, and the link between a clinical activity and the part of the facility accountable for it. | ||
| ## 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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: |
||
|
|
||
| In Care's FHIR-aligned model, a healthcare service maps to the **HealthcareService** resource. It captures: | ||
| ## Key Attributes | ||
|
|
||
| - **Identity** — a display name and free-text details describing the offering | ||
| - **Classification** — a coded service type and an internal type that tells the platform how the service behaves | ||
| - **Placement** — the locations within the facility where the service is delivered | ||
| - **Ownership** — the managing organization (a department or team) accountable for running it | ||
| | Components | What it captures | | ||
| | --- | --- | | ||
| | Name | The name of the healthcare service. This is required. | | ||
| | Internal Type | The kind of service: Pharmacy, Lab, Scheduling, or Store. This is optional. | | ||
| | Extra Details | More information about the service, in free text. You can leave this empty. | | ||
| | Locations | The locations in the facility where the service is available. You must select at least one location. | | ||
| | Managing Organization | The department of the facility that manages the service. This is optional. | | ||
| | Icon | An icon that Care shows for the service in the services list and on the service details page. This is optional. | | ||
|
|
||
| A healthcare service is a *description of an offering*, not an appointment and not a place. It says "this facility offers cardiology, run by the cardiology department, in these rooms" — but the act of seeing a patient is an [encounter](../clinical/encounter.mdx), and the room itself is a [location](../facility/location.mdx). The service is the stable bridge that ties offering, owner, and place together; patients flow through it, but it outlives any single visit. | ||
| ### Managing Organization | ||
|
|
||
| ## Classification | ||
| The form shows this field in a section named Managing Organization. The picker lists the departments of the facility. Select one department, or leave the field empty. See [Department](../../concepts/facility/department.mdx). | ||
|
|
||
| A service carries two labels, and they answer different questions. | ||
|
|
||
| - **Service type** — a coded value drawn from a standard service-type terminology (such as the HL7 `service-type` code system). This is the label a person recognizes: "Cardiology", "General Practice", "Diagnostic Imaging". It answers *what kind of service is this?* | ||
| - **Internal type** — one of `pharmacy`, `lab`, `scheduling`, or `store`. This answers *how should the platform treat this service?* It wires the service into the matching workflow: `pharmacy` into medication dispensing, `lab` into diagnostics, `scheduling` into appointment booking, `store` into supply handling. | ||
|
|
||
| Read service type as the public-facing name and internal type as the behavioral switch that connects the service to the rest of Care. | ||
|
|
||
| ## How it connects | ||
|
|
||
| A healthcare service is owned and placed, never free-floating: | ||
|
|
||
| - It belongs to exactly one [facility](../facility/facility.mdx) — the place that offers it — set automatically from context, never chosen by hand. | ||
| - It is owned by one [facility organization](../access-governance/facility-organization.mdx), the department or team accountable for it. | ||
| - It is delivered across one or more [locations](../facility/location.mdx), so a single service can span several rooms or wards. | ||
|
|
||
| Schedulable services are also what patients reserve time against, through [schedules](../scheduling/schedule.mdx) and [bookings](../scheduling/booking.mdx). The service stays put; the encounters and bookings move through it. | ||
| Note: Care can also use a healthcare service as a resource for appointment scheduling. This document does not cover scheduling setup. | ||
|
|
||
| ## Permissions | ||
|
|
||
| Access to healthcare services is governed by two facility-scoped permissions. | ||
|
|
||
| | Permission | Description | System Roles | | ||
| | --- | --- | --- | | ||
| | `can_write_healthcare_service` | Create, update, or delete a healthcare service on a facility | Facility Admin, Admin | | ||
| | `can_read_healthcare_service` | View healthcare services offered at a facility | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist | | ||
|
|
||
| Roles are granted through a user's membership in an organization or facility, and permissions cascade down the organization tree — a role held at a parent organization applies to the facilities and services beneath it. | ||
| | Permission | What it allows | | ||
| | --- | --- | | ||
| | Can Create Healthcare Service on Facility | Create, edit, or delete a healthcare service. Facility Admin and Admin hold this permission. Care checks this permission on the root department of the facility, not on a sub-department. | | ||
| | Can Read Healthcare Service | View healthcare services. Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, and Pharmacist hold this permission. | | ||
|
|
||
| ## Related | ||
|
|
||
| - Reference: [Healthcare Service (technical)](../../references/facility/healthcare-service.mdx) | ||
| - Concept: [Facility](../facility/facility.mdx) | ||
| - Concept: [Facility Organization](../access-governance/facility-organization.mdx) | ||
| - Concept: [Location](../facility/location.mdx) | ||
| - Concept: [Schedule](../scheduling/schedule.mdx) | ||
| - Flow: [Create a healthcare service](../../flows/facility/healthcare-service/create-healthcare-service.mdx) | ||
| - Flow: [View healthcare services and a service's details](../../flows/facility/healthcare-service/view-healthcare-services.mdx) | ||
| - 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) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as in |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,61 @@ | ||
| --- | ||
| sidebar_position: 7 | ||
| --- | ||
|
|
||
| # Resource Request | ||
|
|
||
| ## Definition | ||
|
|
||
| A **resource request** in Care is a request that one facility sends to another facility. The request asks for a resource that a patient or a facility needs. A request can ask for clinical care and social support, comfort devices, medicines, or financial support. | ||
|
|
||
| ## Key Attributes | ||
|
|
||
| | Components | What it captures | | ||
| | --- | --- | | ||
| | Request Title | The short title of the request. This is required. | | ||
| | Is this an Emergency? | Whether the request is urgent. Select Yes or No. | | ||
| | Category | The kind of resource that you need. This is required. | | ||
| | Reason of Request | Why you need the resource. This is required. | | ||
| | Name of Contact Person at Facility | The name of the person to contact about this request. This is required. | | ||
| | Contact Person Number | The phone number to contact about this request. This is required. | | ||
| | Facility for Care Support | The facility that you ask for help. This is required. | | ||
| | Status | The current state of the request. See Status below. | | ||
| | Assigned to | The user at the Facility for Care Support who handles the request. This is optional. Care shows this field only when you update a request, not when you create one. | | ||
| | Linked Patient | The patient that this request is for. | | ||
|
|
||
| ### Category | ||
|
|
||
| Category records the kind of resource that you need. Select one of these values: | ||
|
|
||
| - Clinical Care and Social Support | ||
| - Comfort Devices | ||
| - Medicines | ||
| - Financial | ||
| - Other | ||
|
|
||
| ### Status | ||
|
|
||
| | Status | Description | | ||
| | --- | --- | | ||
| | Pending | The request waits for a response. | | ||
| | Approved | The Facility for Care Support approved the request. | | ||
| | Transportation to be arranged | Someone must arrange transport for this request. | | ||
| | Transfer in progress | The transfer has started. | | ||
| | Completed | The request is complete. | | ||
| | Rejected | The Facility for Care Support rejected the request. | | ||
| | Cancelled | The request is cancelled. | | ||
|
|
||
| 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A reference already exists at |
||
|
|
||
| Care does not have a dedicated set of permissions for resource requests. Anyone who belongs to a facility organization connected to the request can view, create, update, or delete that request. A connected user can also change the status of the request. Care connects a request to the facility that sent it and to the Facility for Care Support. Care does not separate who can create a request from who can approve one. | ||
|
|
||
| ## Related | ||
|
|
||
| - Flow: [Create a resource request](../../flows/facility/resource-request/create-resource-request.mdx) | ||
| - Flow: [View resource requests](../../flows/facility/resource-request/view-resource-requests.mdx) | ||
| - 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) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Broken-link risk: the conventions say extensionless links are used only for the translated docs, and then relative to the file — |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| { | ||
| "label": "Device", | ||
| "position": 4, | ||
| "key": "facility-device-flows" | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.