diff --git a/static/media/clinical/notes/1. Start a discussion.mp4 b/static/media/clinical/notes/1. Start a discussion.mp4 new file mode 100644 index 00000000..dfe923f5 Binary files /dev/null and b/static/media/clinical/notes/1. Start a discussion.mp4 differ diff --git a/static/media/clinical/notes/1. Start a discussion.png b/static/media/clinical/notes/1. Start a discussion.png new file mode 100644 index 00000000..f241b317 Binary files /dev/null and b/static/media/clinical/notes/1. Start a discussion.png differ diff --git a/static/media/clinical/notes/2. Post a message to a discussion.mp4 b/static/media/clinical/notes/2. Post a message to a discussion.mp4 new file mode 100644 index 00000000..b50726de Binary files /dev/null and b/static/media/clinical/notes/2. Post a message to a discussion.mp4 differ diff --git a/static/media/clinical/notes/2. Post a message to a discussion.png b/static/media/clinical/notes/2. Post a message to a discussion.png new file mode 100644 index 00000000..481996ad Binary files /dev/null and b/static/media/clinical/notes/2. Post a message to a discussion.png differ diff --git a/static/media/clinical/notes/3. Find discussions for a patient or an encounter.mp4 b/static/media/clinical/notes/3. Find discussions for a patient or an encounter.mp4 new file mode 100644 index 00000000..3ee5b783 Binary files /dev/null and b/static/media/clinical/notes/3. Find discussions for a patient or an encounter.mp4 differ diff --git a/static/media/clinical/notes/3. Find discussions for a patient or an encounter.png b/static/media/clinical/notes/3. Find discussions for a patient or an encounter.png new file mode 100644 index 00000000..9351a3f7 Binary files /dev/null and b/static/media/clinical/notes/3. Find discussions for a patient or an encounter.png differ diff --git a/versioned_docs/version-3.1/concepts/clinical/care-team.mdx b/versioned_docs/version-3.1/concepts/clinical/care-team.mdx index 54642f4a..2142065f 100644 --- a/versioned_docs/version-3.1/concepts/clinical/care-team.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/care-team.mdx @@ -1,52 +1,54 @@ --- -sidebar_position: 15 +sidebar_position: 11 --- -# Care team +# Clinical - Care Team ## Definition -The **care team** of an [encounter](../clinical/encounter.mdx) is the list of users who look after the patient during that episode of care. Each member holds a practitioner role, such as a physician or a nurse. The first member in the list is the primary member, and Care shows that member on the encounter card and on printed documents. A care team belongs to one encounter, so a patient with two open encounters has two separate care teams. +The **[care team](https://build.fhir.org/encounter.html#Encounter.participant)** lists the staff who look after a patient during one encounter. Each entry names a staff member and the clinical role that person holds on that encounter. Care keeps the team as a list on the encounter. Care does not keep the team as a separate record with its own identifier, status, or time period. The list matches the participant part of the FHIR R5 Encounter resource. It does not match the standalone [FHIR CareTeam](https://build.fhir.org/careteam.html) resource. ## Key Attributes | Components | What it captures | | --- | --- | -| Member | The Care user who takes part in the episode of care. | -| Role | The practitioner role of the member for this encounter, such as physician or nurse. | -| Primary | The first member in the list. Care shows this member as the main contact for the encounter. | -| Order | The position of each member in the list. The order sets which member is primary. | +| Staff member | The person who looks after the patient during the encounter. | +| Role | The clinical role that the staff member holds on the encounter. | +| Primary member | The one member who leads the care of the patient. | -### Member +### Role -You select a member in two steps. First you select a facility department. Then you select a user from that department. A user can appear only once in a care team. Care shows an error if you add the same user two times. +Care takes the roles from a clinical terminology set. The list of roles that you can choose differs between deployments. -### Role +Note: The roles available to you depend on your deployment's configuration. -The role comes from the Practitioner Role value set. The value set holds the SNOMED CT healthcare professional and healthcare-related organization codes. You must select a role for each member. +### Primary member -The care team has no status of its own. It follows the encounter: when the encounter is complete, you can no longer change the care team. +Care marks one member of the list as Primary. Care always treats the first person in the list as the primary member. To change the primary member, move a different person to the top of the list. -## Permissions +### How Care saves the team + +Care saves the whole team together as one list each time the team changes. Every change replaces the complete list. There is no separate action to add one member or to remove one member. -Care controls the care team through the encounter, not through a separate permission of its own. +### Use in encounter lists + +Care lets you filter the encounters of a patient by care team member. Keep the team correct, so that these filters show the right encounters. + +## Permissions -| Permission | Description | System Roles | +| Permission | Who holds it | What it allows | | --- | --- | --- | -| `can_read_encounter` | See the care team of an encounter. | Admin, Doctor, Nurse, Facility Admin | -| `can_write_encounter` | Add a member, remove a member, or change the primary member. | Admin, Doctor, Nurse, Facility Admin | +| Update Encounter non clinical | Administrator, Doctor, Nurse, Facility Administrator | Add members, remove members, and reorder members. | -Two more rules apply to a change: +A user who can open the encounter but cannot change it sees the same list in read-only form. -- Care refuses the change when the encounter is in a completed state. -- Care refuses a member who cannot see the encounter. +## Where to find it -Users get these roles through their organization and facility memberships. Permissions cascade down the organization tree, so a role at a parent organization applies to the facilities and encounters below it. +Open an encounter. Select **Encounter Actions**, then select **Manage Care Team**. You can also select **Manage Care Team** on the side panel of the **Overview** tab. ## Related -- Concept: [Encounter](../clinical/encounter.mdx) -- Concept: [Patient](../clinical/patient) -- Flow: [Manage the care team of an encounter](../../flows/clinical/encounter/manage-encounter-care-team.mdx) -- Reference: [Care team](../../references/clinical/care-team.mdx) -- Reference: [Encounter](../../references/clinical/encounter.mdx) +- Flow: [Add care team members](../../flows/clinical/care-team/add-care-team-members.mdx) +- Flow: [View the care team](../../flows/clinical/care-team/view-the-care-team.mdx) +- Flow: [Modify the care team](../../flows/clinical/care-team/modify-the-care-team.mdx) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/consent.mdx b/versioned_docs/version-3.1/concepts/clinical/consent.mdx index 7417dbdb..b3ab3787 100644 --- a/versioned_docs/version-3.1/concepts/clinical/consent.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/consent.mdx @@ -1,84 +1,89 @@ --- -sidebar_position: 12 +sidebar_position: 8 --- # Consent -A **consent** records a patient's decision to permit or refuse a category of activity — treatment, research participation, sharing of their information, or a directive about end-of-life care. It is the auditable proof that a choice was made, by or for the patient, before that activity went ahead. +## Definition -## What it represents +A **[consent](https://build.fhir.org/consent.html)** in Care is a record of the permission or the refusal that a patient gives for a treatment, for a research study, or for the sharing of information. Each consent belongs to one encounter. Care shows the consents of an encounter on the **Consents** tab of that encounter, as a list of cards. -In Care's FHIR-aligned model, a consent maps to the **Consent** resource. Each record answers four questions: +## Key Attributes -- **What is being decided** — a category such as treatment, research, privacy of information, or an advance directive like a do-not-resuscitate order -- **What was decided** — a single decision to *permit* or *deny* it -- **When it applies** — the date it was recorded, plus an optional validity window -- **How it was confirmed** — who witnessed the decision and how, with any signed form attached alongside +| Components | What it captures | +| --- | --- | +| Status | The current state of the consent. | +| Category | The subject that the patient gives permission or refusal for. | +| Consent Decision | Whether the patient permits or denies the subject of the consent. | +| Consent Given On | The date and time when the patient gives the consent. | +| Consent Valid From | The date and time from which the consent is valid. | +| Consent Valid Until | The date and time until which the consent is valid. | +| Note | Free text that records more information about the consent. | +| Supporting Documents | Files that you attach to the consent, for example a scanned signed consent form. | -The key thing to understand is that a consent is *not* a permission setting. It does not grant anyone access to the system. It documents the **patient's** clinical and legal choice — a fact about the patient's care, not a rule about staff. Who can act in Care is governed separately by the [permission model](../../references/access-governance/permission.mdx). +### Consent Decision -## Lifecycle +Consent Decision records the answer of the patient. Select one of these values: -A consent's status mirrors whether its decision is currently in force: +| Consent Decision | Description | +| --- | --- | +| Permit | The patient allows the subject of the consent. | +| Deny | The patient refuses the subject of the consent. | -```text -draft → active → inactive - ↘ not_done - ↘ entered_in_error -``` +On the consent card, Care shows **Permitted** for Permit, and **Denied** for Deny. -- **draft** — recorded but not yet in force -- **active** — in force; the decision currently governs the activity -- **inactive** — no longer in force, for example once its validity window has passed -- **not_done** — the consent activity never took place -- **entered_in_error** — recorded by mistake; kept for audit but disregarded +### Category -Status is a plain field on the record. Moving a consent to `entered_in_error` corrects the history without deleting it, and changing status has no automatic side effect elsewhere in the chart — nothing downstream is unlocked or revoked. +Category records the subject of the consent. The consent form shows these categories, with a short description for each one: -## Categories +| Category | Description | +| --- | --- | +| Research | Consent to take part in a research protocol and to share information. | +| Privacy Consent | Consent to collect, access, use, or share information. | +| Treatment | Consent to undergo a specific treatment. | +| Do Not Resuscitate | Consent to not receive CPR or resuscitation in a cardiac event. | +| Advance Directive | Consent that the patient gives before a possible need for medical treatment. | +| Advance Care Directive | Consent for the actions to take if the patient can no longer decide. | -The category names what the patient is deciding about. Care recognises seven: +Note: Care also holds a **Comfort Care** category, but the consent form has no option for it. You cannot select Comfort Care. This is a known gap in the product. -| Category | What it covers | -| --- | --- | -| Treatment | Consent to a clinical treatment or procedure | -| Research | Consent to take part in research | -| Patient privacy | Consent to disclose or share the patient's information | -| DNR | A do-not-resuscitate directive | -| Comfort care | A comfort or palliative care directive | -| Advance care directive | A directive about future care while the patient can still decide | -| Advance directive (other) | Any other advance directive | +### Verification -Every consent carries exactly one decision — **permit** or **deny** — so a refusal is captured with the same weight and auditability as an approval. A documented "no" is as much a part of the record as a "yes". +Care can hold a verification for a consent. A verification records who confirmed the consent, when they confirmed it, and the type of the confirmation. The type is **Family** for a confirmation by a family member or a representative. The type is **Validation** for a confirmation by the patient. -## How it connects +Note: The current version of Care has no screen to add, show, or remove a verification. This is a known gap in the product. For more information, see [Verify a consent](../../flows/clinical/consent/verify-a-consent.mdx). -A consent is always attached to a single [encounter](../clinical/encounter.mdx), and the owning [patient](../clinical/patient) is reached through that encounter. The encounter is fixed at creation and cannot be moved to a different visit later — this is deliberate, because it preserves *when and in what context* the decision was made. +### Changes after creation -Two neighbouring records hang off a consent: +Care fixes the Category, the Consent Decision, the Consent Given On date, and the validity period when you record the consent. The edit form does not show these fields. After creation, you can change the Status and the Note. -- **Documents** — a signed consent form or scanned file can be attached, so the paper trail lives beside the structured record -- **Verifiers** — each verification names the user who confirmed the consent, so a reviewer can later see exactly who witnessed it +## Status + +| Status | Description | +| --- | --- | +| Draft | You prepared the consent, but it is not in effect. | +| Active | The consent is in effect. | +| Inactive | The consent is no longer in effect. | +| Not Done | The consent did not happen. | +| Entered in Error | Someone recorded the consent by mistake. | ## Permissions -There is no separate consent permission set. Because a consent always hangs off an encounter, it is governed by the **encounter** clinical-data permissions, with patient-level clinical-data access also accepted for reads. +| Action | Permission | +| --- | --- | +| View a consent | Can view clinical data about patients, or Can Read encounter related clinical data. | +| Record a consent | Update Encounter related clinical data. | +| Update a consent | Update Encounter related clinical data. | -| Permission | Description | System Roles | -| --- | --- | --- | -| `can_write_encounter_clinical_data` | Create, update, or delete a consent on an encounter, and add or remove its verifications (blocked once the encounter is closed) | Admin, Doctor, Nurse, Facility Admin | -| `can_view_clinical_data` | View a patient's clinical record, including their consents | Staff, Doctor, Nurse, Admin, Facility Admin | -| `can_read_encounter_clinical_data` | Read consents via the encounter when patient-level clinical-data access is absent | Admin, Doctor, Nurse, Facility Admin | +The Admin, Doctor, Nurse, and Facility Admin roles hold the **Update Encounter related clinical data** permission. -Roles are granted through organization, facility, or patient memberships, and permissions cascade down the organization tree — a role held higher up applies to the patients and consents beneath it. +Note: Care shows the buttons that record and change a consent only when the encounter is active, and only when you open the encounter from the facility. ## Related -- Reference: [Consent (technical)](../../references/clinical/consent.mdx) -- Concept: [Encounter](../clinical/encounter.mdx) -- Concept: [Patient](../clinical/patient) -- Reference: [Permission](../../references/access-governance/permission.mdx) - -## FHIR reference - -Care's consent aligns with the FHIR **Consent** resource: its status, category, decision, and validity period map to their FHIR counterparts, modelling a patient's recorded choice to permit or deny a category of activity. +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) +- Concept: [Files](../../concepts/clinical/files.mdx) +- Flow: [Record a consent](../../flows/clinical/consent/record-a-consent.mdx) +- Flow: [View consents](../../flows/clinical/consent/view-consents.mdx) +- Flow: [Update a consent](../../flows/clinical/consent/update-a-consent.mdx) +- Flow: [Verify a consent](../../flows/clinical/consent/verify-a-consent.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/diagnostic-report.mdx b/versioned_docs/version-3.1/concepts/clinical/diagnostic-report.mdx index 54c33194..26b2eb81 100644 --- a/versioned_docs/version-3.1/concepts/clinical/diagnostic-report.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/diagnostic-report.mdx @@ -2,73 +2,70 @@ sidebar_position: 7 --- -# Diagnostic Report +# Clinical - Diagnostic Report -A **diagnostic report** is the formal result of a diagnostic test or investigation — the lab panel, imaging study, or pathology workup that answers a clinical question. It closes the loop on an order: each report fulfils a single request and carries the findings, and the clinician's interpretation of them, back into the patient's record. +## Definition -## What it represents +A **[diagnostic report](https://build.fhir.org/diagnosticreport.html)** in Care holds the result of a laboratory, imaging, or other diagnostic service request. Each diagnostic report answers one service request. Care takes the patient, the encounter, and the facility from that service request. The report groups the individual result values, a written conclusion, and the attached result documents in one place. -In Care's FHIR-aligned model, a diagnostic report maps to the **DiagnosticReport** resource. It captures: +## Key Attributes -- **What was investigated** — the service section it belongs to (for example, laboratory or radiology) and the specific test or panel performed -- **The findings** — the individual measured results, which live as observations attached to the report -- **The interpretation** — a clinician's conclusion summarising what the results mean, plus any free-text notes -- **The clinical context** — the patient, the encounter it was produced under, and the order it answers +| Components | What it captures | +| --- | --- | +| Status | The stage the report has reached, from first registration to the final result. | +| Category | The diagnostic service section that produced the result, such as the laboratory section or the imaging section. A report has one category. | +| Code | The test or observation that the report is about. This attribute uses a LOINC code and is optional. | +| Note | Extra remarks about the report. | +| Conclusion | A free text summary of the result. | +| Observations | The individual result values that belong to the report. | -A diagnostic report is not the raw measurement itself. The individual values — a glucose level, a haemoglobin count — are **observations**; the report is the container that groups them under one investigation, names it, and adds the human interpretation on top. That layering is the point: the observations are facts, and the report is the clinically signed-off reading of those facts taken together. +### Service request -## Lifecycle +A diagnostic report always belongs to one service request. You do not select a patient, an encounter, or a facility on the report. Care takes all three from the service request that the report answers. -A report moves through a sequence of result-readiness states as findings come in and are verified. +### Observations -```text -registered → partial → preliminary → final -``` +The observations hold the measured or observed result values. You can add or change observations while the status of the report is not Final. After you set the status to Final, Care locks the observations. You cannot add a new observation or change an existing one. -- **registered** — the report exists in the system but no results have been attached yet -- **partial** — some results are in, but the report is still incomplete -- **preliminary** — results are present but not yet verified or signed off -- **final** — the report is complete and verified; it is the authoritative answer +### Attachments -Not every report passes through every state — a simple report may go straight from `registered` to `final`. The status describes how trustworthy and complete the results are at any moment, which matters when a clinician acts on a preliminary value before final sign-off. +A diagnostic report can carry file attachments, such as a scanned copy of a printed report. Care stores these files with the Files feature and attaches them to the report. -## How it connects +### Specimen -A diagnostic report never stands alone — it sits at the centre of an ordering-and-results chain: +Care does not link a diagnostic report to a specimen directly. A report and a specimen connect to each other only through the service request that they share. -- **Service request** — every report fulfils exactly one request. The order is placed first; the report is the answer to it, and it cannot exist without the request it resolves. -- **Observation** — the individual results that make up the report. One report typically groups many observations. -- **Specimen** — for lab work, the sample the investigation was run on is tracked through the request and feeds the report. -- **Patient and encounter** — the report is anchored to the patient it concerns and the encounter it was produced under. Both are inherited from the originating order, not chosen on the report. +## Status -This is why you create a [Service Request](../clinical/service-request.mdx) before a report can be filed against it, and why deleting the patient, encounter, or originating request also removes the reports tied to them. +| Status | Description | +| --- | --- | +| Registered | A user started the report, but the report holds no results yet. | +| Preliminary | The report holds early results that can still change. | +| Partial | The report holds some, but not all, of the expected results. | +| Final | The report is complete. Care locks the results against further changes. | -## Classification - -Two coded fields describe what the report is, drawn from standard terminologies so reports stay comparable across facilities: - -- **Category** — the diagnostic service section the report belongs to, such as laboratory, radiology, or pathology. Required, and it groups reports by the kind of investigation. -- **Code** — the specific test or panel performed, named using LOINC. Optional, but it lets a report be identified precisely (a particular metabolic panel rather than just "laboratory"). - -Because these are coded concepts rather than free text, the same test means the same thing everywhere — which is what makes reports searchable and comparable across a deployment. +Care uses these four statuses only. Care does not enforce an order between them. Any user with the correct permission can set any of the four statuses directly. ## Permissions -Access to diagnostic reports is governed by the following permissions. +| Permission | Roles | +| --- | --- | +| Can Create Diagnostic Report on Facility | Facility Admin, Admin, Doctor, Nurse | +| Can Read Diagnostic Report | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer | + +You need Can Create Diagnostic Report on Facility to create or update a diagnostic report. You need Can Read Diagnostic Report to view a diagnostic report. -| Permission | Description | System Roles | -| --- | --- | --- | -| `can_write_diagnostic_report` | Create and update a report (including upserting its observations), checked against the originating service request | Facility Admin, Admin, Doctor, Nurse | -| `can_read_diagnostic_report` | Retrieve a report, and list reports filtered by their encounter or service request | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer | -| `can_view_clinical_data` | List a patient's reports when no encounter or service request filter is supplied, authorized against the patient | Facility Admin, Admin, Doctor, Nurse, Staff | +## Where to find it -Roles are granted through a user's membership in an organization, facility, or patient, and permissions cascade down the organization tree — so a role held higher up applies to the facilities and reports beneath it. +Care shows diagnostic reports on the **Diagnostic Reports** tab of an encounter. You fill in a report from the detail page of its service request. ## Related -- Reference: [Diagnostic Report (technical)](../../references/clinical/diagnostic-report.mdx) -- Concept: [Service Request](../clinical/service-request.mdx) -- Concept: [Observation](../clinical/observation.mdx) -- Concept: [Specimen](../clinical/specimen.mdx) -- Concept: [Encounter](../clinical/encounter.mdx) -- Concept: [Patient](../clinical/patient) +- Flow: [Enter diagnostic report results](../../flows/clinical/diagnostic-report/enter-diagnostic-report-results.mdx) +- Flow: [View a diagnostic report](../../flows/clinical/diagnostic-report/view-a-diagnostic-report.mdx) +- Flow: [Update a diagnostic report](../../flows/clinical/diagnostic-report/update-a-diagnostic-report.mdx) +- Flow: [Print a diagnostic report](../../flows/clinical/diagnostic-report/print-a-diagnostic-report.mdx) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) +- Concept: [Service Request](../../concepts/clinical/service-request.mdx) +- Concept: [Specimen](../../concepts/clinical/specimen.mdx) +- Concept: [Files](../../concepts/clinical/files.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/files.mdx b/versioned_docs/version-3.1/concepts/clinical/files.mdx new file mode 100644 index 00000000..053b6804 --- /dev/null +++ b/versioned_docs/version-3.1/concepts/clinical/files.mdx @@ -0,0 +1,77 @@ +--- +sidebar_position: 9 +--- + +# Clinical - Files + +## Definition + +A **file** in Care is an attachment that you upload and link to another record. You can +attach a file to a Patient, an Encounter, a Consent, a Diagnostic Report, or a Service +Request. Files keep scans, photos, recordings, and documents together with the record +they belong to. Care shows the attachments in a **Files** tab on the Patient page and on +the Encounter page. + +Note: Care stores files as generic attachments. This module has no formal FHIR R5 +resource mapping in Care. + +## Key Attributes + +| Components | What it captures | +| --- | --- | +| File Name | The name that Care shows for the attachment. You can change this name. | +| Attached to | The record that the file belongs to: a Patient, an Encounter, a Consent, a Diagnostic Report, or a Service Request. | +| Category | An internal classification of the file. | +| Upload status | Whether the upload of the file is complete. | +| Archived | Whether you removed the file from active use. Care shows this only after the upload is complete. | + +### Category + +Category is an internal classification. You cannot select a category when you add a file. +Most category values have no visible label in the Care screens today. + +### How you add a file + +You can add a file in three ways: + +- Choose a file from your device. +- Capture a photo with the camera. +- Record audio in the browser. + +The maximum size of one file is 100 MB. Care accepts common image, video, and audio +types. Care also accepts text documents, office documents, and PDF files. + +### How you open a file + +Care shows a preview in the browser for images, PDF files, video files, and HTML files. +For an audio file, Care shows a separate playback control. Care shows no preview for +other file types. To open a file of another type, download it. + +### What you can do with a file + +You can rename a file, archive a file, or download a file. To archive a file, you must +give a reason. You cannot undo an archive action. Care has no permanent delete action. +Archiving is the only way to remove a file from active use. + +## Permissions + +| Action | Permission | +| --- | --- | +| View a file | The same permission that lets you view clinical data for the Patient or the Encounter. | +| Upload, rename, or archive a file | The same permission that lets you write to the Patient or the Encounter. | + +For a file that belongs to an Encounter, the Encounter must not be inactive. If the +Encounter is inactive, you cannot upload, rename, or archive its files. + +## Related + +- Flow: [Upload a file](../../flows/clinical/files/upload-a-file.mdx) +- Flow: [View or preview a file](../../flows/clinical/files/view-or-preview-a-file.mdx) +- Flow: [Rename a file](../../flows/clinical/files/rename-a-file.mdx) +- Flow: [Archive a file](../../flows/clinical/files/archive-a-file.mdx) +- Flow: [Download a file](../../flows/clinical/files/download-a-file.mdx) +- Concept: [Patient](../../concepts/clinical/patient) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) +- Concept: [Consent](../../concepts/clinical/consent.mdx) +- Concept: [Diagnostic Report](../../concepts/clinical/diagnostic-report.mdx) +- Concept: [Service Request](../../concepts/clinical/service-request.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/notes.mdx b/versioned_docs/version-3.1/concepts/clinical/notes.mdx index 1bc54b40..0a33c7db 100644 --- a/versioned_docs/version-3.1/concepts/clinical/notes.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/notes.mdx @@ -1,64 +1,65 @@ --- -sidebar_position: 13 +sidebar_position: 12 --- -# Clinical Notes +# Notes -A **clinical note** in Care is the care team's written commentary about a patient — the place where staff record narrative, hand-offs, and discussion in their own words rather than in structured fields. Notes are organized into threads, so a single topic stays together as a conversation instead of scattering across the record. +## Definition -## What it represents +**Clinical Notes** is the space where staff record and exchange written notes about a patient. Care groups the messages into titled discussions, so different topics stay separate. You find Clinical Notes in the **Notes** tab, which shows a panel called **Discussions**. -In Care's FHIR-aligned model, clinical notes map to the **Communication** resource — running written exchanges about a patient. A note thread holds: +Clinical Notes is a Care feature for staff collaboration. Care does not map Clinical Notes to an FHIR R5 resource. -- **A subject** — every thread is anchored to one patient, and optionally narrowed to a single encounter -- **A title** — a short label for what the thread is about -- **Messages** — the entries posted into the thread over time by the care team -- **A preserved history** — authorship, timestamps, and prior versions of every edited message +## Key Attributes -A note is not a substitute for structured clinical data. Diagnoses belong in [conditions](../clinical/condition.mdx), allergies in [allergy records](../clinical/allergy-intolerance.mdx), and measurements in [observations](../clinical/observation.mdx). Notes are the human layer that ties that data together — the reasoning, context, and discussion that coded fields can't hold. +A discussion groups related messages under one title. A message is one entry in a discussion. -## Threads and messages +| Components | What it captures | +| --- | --- | +| Title | The subject of the discussion. The title holds up to 255 characters. | +| Message | The text of one entry in a discussion. The text supports Markdown formatting. | +| Author | The staff member who wrote the message. Care records this for you. | +| Time | The date and time of the message. Care records this for you. | -Notes live in a two-level structure: **threads** that hold **messages**. +A discussion holds a title only. A message holds text only. This module has no status, no category, and no coded value. -- A **thread** is one conversation, anchored to a patient and optionally to one of that patient's encounters. -- A **message** is a single entry inside a thread. Many people can add messages to the same thread over time. +### Encounter discussions and patient discussions -That anchoring gives a thread its scope: +Care keeps two separate spaces for discussions: -| Scope | What it means | Typical use | -| --- | --- | --- | -| Patient-level | Attached to the patient, not to any one visit | Longitudinal commentary across encounters — care coordination, ongoing concerns | -| Encounter-level | Attached to a specific [encounter](../clinical/encounter.mdx) | Discussion tied to one admission or visit — shift hand-offs, ward notes | +- Encounter discussions belong to one [encounter](../../concepts/clinical/encounter.mdx). You see them in the Notes tab of that encounter. +- Patient discussions belong to the patient. You see them in the Notes tab of the patient profile. + +The two lists never overlap. A patient discussion never appears inside an encounter. An encounter discussion never appears on the patient profile. -Because threads hang off the patient record, they follow the patient over time. Deleting a patient removes their threads; deleting a thread removes its messages. +### Order of discussions and messages -## Edit history +Care lists the discussions with the most recent first. Inside a discussion, the newest message appears at the bottom. Care loads older messages 20 at a time as you scroll up. -A note is meant to be an auditable record, not just a scratchpad. When someone edits a message, the new text becomes the visible body — but the previous version is never thrown away: +### Permanence -```text -Posted → Edited → Edited again -``` +Care shows no way to delete a discussion. Care shows no way to delete a message. After you send a message, the message stays in the discussion. -Each edit appends the prior text, its author, and the time of the change to the message's history, oldest first. The platform maintains this trail server-side; clients cannot rewrite or erase what was already said. So a thread reliably shows not only what the team currently thinks, but what was written and when. +### Attachments and mentions -## Permissions +Care does not support file attachments in messages. Care does not support user mentions in messages. -Notes have no permission file of their own. Access follows the [patient](../clinical/patient) and [encounter](../clinical/encounter.mdx) permissions, since every thread is anchored to a patient and may be scoped to an encounter. +### Who can see and write -| Permission | Description | System Roles | +| Action | Permission | Roles | | --- | --- | --- | -| `can_write_patient` | Create or update a patient-scoped thread or message (used when the note is not tied to an encounter) | Staff, Doctor, Nurse, Administrator, Admin, Facility Admin | -| `can_write_encounter_clinical_data` | Create or update an encounter-scoped thread or message (the encounter must not be closed) | Admin, Doctor, Nurse, Facility Admin | -| `can_view_clinical_data` | Read a patient's clinical record, including their note threads and messages | Staff, Doctor, Nurse, Admin, Facility Admin | -| `can_read_encounter_clinical_data` | Read encounter-scoped threads and messages when patient-level clinical access is not granted | Admin, Doctor, Nurse, Facility Admin | +| See encounter discussions and messages | Can Read encounter related clinical data | Doctor, Nurse, Admin, Facility Admin | +| Start an encounter discussion, or post a message in one | Update Encounter related clinical data | Doctor, Nurse, Admin, Facility Admin | +| See patient discussions and messages | Can view clinical data about patients | Staff, Doctor, Nurse, Admin, Facility Admin | +| Start a patient discussion, or post a message in one | Can Update a Patient's data | Staff, Doctor, Nurse, Administrator, Admin, Facility Admin | + +If the encounter is closed, you cannot start a discussion in it. You also cannot post a message in it. Care treats an encounter as closed when its status is Completed, Cancelled, Discontinued, or Entered in error. -Roles are granted through a person's organization, facility, or patient membership, then cascade down the organization tree — access granted at a parent organization flows to the facilities and patients beneath it. +Note: No deployment setting changes how Clinical Notes behaves. ## Related -- Reference: [Notes (technical)](../../references/clinical/notes.mdx) -- Concept: [Patient](../clinical/patient) -- Concept: [Encounter](../clinical/encounter.mdx) -- Concept: [Observation](../clinical/observation.mdx) +- Flow: [Start a discussion](../../flows/clinical/notes/start-a-discussion.mdx) +- Flow: [Post a message to a discussion](../../flows/clinical/notes/post-a-message.mdx) +- Flow: [Find discussions for a patient or an encounter](../../flows/clinical/notes/find-discussions.mdx) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/questionnaire-response.mdx b/versioned_docs/version-3.1/concepts/clinical/questionnaire-response.mdx index 6011544a..a9e99f33 100644 --- a/versioned_docs/version-3.1/concepts/clinical/questionnaire-response.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/questionnaire-response.mdx @@ -1,66 +1,68 @@ --- -sidebar_position: 14 +sidebar_position: 10 --- # Questionnaire Response -A **questionnaire response** is the set of answers a clinician or staff member records when they fill in a [questionnaire](../definitions/questionnaire.mdx) for a patient. It turns a blank form — a triage screen, a vitals chart, an intake assessment — into a permanent, attributed piece of that patient's clinical record. +## Definition -## What it represents +A **[questionnaire response](https://build.fhir.org/questionnaireresponse.html)** in Care is the record of one submitted form. Care files a response each time a user submits a form for a patient. Care also files a response when a user saves a structured clinical record, such as an allergy or a diagnosis. -In Care's FHIR-aligned model, a questionnaire response maps to the **QuestionnaireResponse** resource. It captures: +This module explains how to read the submission history. To learn how to fill in a form, read the module of that form. -- **The answers** — what was entered for each question, kept both as the raw submission and as an extracted, query-friendly form -- **Who and what it is about** — the patient, and the encounter it was recorded in when answered during a visit -- **Which form was answered** — a link back to the questionnaire definition that was filled in -- **Provenance** — who submitted it and when, maintained automatically by the platform +## Key Attributes -A questionnaire response is not the questionnaire itself. The questionnaire is the reusable template (the questions and their rules); the response is one patient's filled-in copy. Submitting the same form for ten patients produces ten responses against a single questionnaire. +| Components | What it captures | +| --- | --- | +| Form | The form that the response comes from. A response that a structured clinical record creates has no form. | +| Filed By | The user who filed the response. | +| Filed On | The date and the time of the submission. | +| Status | The state of the response. | +| Answers | The values that the user entered in the form, with the note on each answer. | +| Patient | The patient that the response belongs to. | +| Encounter | The encounter that the response belongs to. A patient-level form has no encounter. | -## How a response is captured +### Where Care shows responses -Answers are not edited directly into a response record. They arrive through the **submit flow**: one submission carries the questionnaire being answered, the patient, the encounter if there is one, and the answer to every question. Care validates that whole payload against the questionnaire definition — required questions, allowed values, coded options — and only then writes the response. A submission that fails validation produces no response at all. +Care shows the responses of a patient in three places: -This is why a response is best thought of as a snapshot. It records what was answered at the moment of submission, attributed to the person who submitted it, against the patient and encounter in scope at that time. +- The **Updates** tab of the patient. This tab lists the responses to patient-level forms. +- The **Responses** tab of the encounter. This tab lists the responses to the forms of that encounter. +- The **Clinical History** page of the patient. The **Responses** section lists the responses across all encounters of the patient. -## Lifecycle +### Status -A response is finalised the moment it is submitted; it has no draft state of its own. +Care uses two states for a response. -```text -completed → entered_in_error -``` +| Status | Description | +| --- | --- | +| Completed | The user filed the response, and the answers are valid. | +| Entered in Error | The user filed the response by mistake. Care shows the response as invalid. | -- **completed** — the response is finalised and part of the record (this is the default and normal state) -- **entered_in_error** — the response was recorded by mistake; rather than deleting it, it is flagged so the history stays auditable +You cannot change a response after Care marks it as entered in error. -Because answers are not re-edited after submission, the only change applied to an existing response is marking it `entered_in_error`. Drafts, where they exist, live one level up in the **form submission** envelope (`draft → submitted`) before a response is written — see the technical reference. - -## How it connects - -- **Patient** — every response belongs to a [patient](../clinical/patient); it is governed by that patient's permission set -- **Encounter** — when answered during a visit, the response is tied to that [encounter](../clinical/encounter.mdx), giving the answers a clinical context and timestamp -- **Questionnaire** — the response points back to the [questionnaire](../definitions/questionnaire.mdx) it answered; rendering the answers joins them against that definition so labels stay human-readable -- **Structured data** — alongside the raw answers, a response can hold an extracted, query-friendly copy of those values. This is what lets a vitals form become real observations, or an allergy form become allergy records, rather than leaving the data locked inside a form +Note: A time limit applies to the Entered in Error status. After that time, only a system administrator can mark the response as entered in error. Your deployment's configuration sets the time limit. ## Permissions -Questionnaire responses have no permission slug of their own. The read-only-plus-update viewset gates each action through the **patient** and **encounter** permission sets, choosing which permission to check based on whether the response is tied to an encounter. +| Permission | What it allows | +| --- | --- | +| Can view questionnaire responses on patient | View the responses of a patient. | +| Can view clinical data about patients | View the responses of an encounter of the patient. | +| Can Read encounter related clinical data | View the responses of an encounter. | +| Can submit questionnaire about patients | Mark a patient-level response as entered in error. | +| Can submit questionnaire about patient encounters | Mark a response of an encounter as entered in error. | -| Permission | Description | System Roles | -| --- | --- | --- | -| `can_view_questionnaire_responses` | View the questionnaire responses on a patient when the response is not linked to an encounter | Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator, Pharmacist | -| `can_view_clinical_data` | View clinical data about a patient; satisfies viewing an encounter-linked response from the patient side | Staff, Doctor, Nurse, Admin, Facility Admin | -| `can_read_encounter_clinical_data` | Read an encounter's clinical data; alternatively satisfies viewing an encounter-linked response from the encounter side | Admin, Doctor, Nurse, Facility Admin | -| `can_submit_patient_questionnaire` | Submit a questionnaire about a patient; required to update (correct) a response not linked to an encounter | Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator | -| `can_submit_encounter_questionnaire` | Submit a questionnaire about a patient encounter; required to update (correct) an encounter-linked response | Staff, Doctor, Nurse, Admin, Facility Admin | +## FHIR R5 alignment -Reads on an encounter-linked response are allowed if **either** `can_view_clinical_data` (patient) or `can_read_encounter_clinical_data` (encounter) is held; responses without an encounter fall back to `can_view_questionnaire_responses`. Updates are limited to marking a response `entered_in_error` within a short edit window and require the matching submit permission. Roles are granted through a user's organization, facility, or patient memberships, and permissions cascade down the organization tree — so access to a patient's responses follows from access to the patient. +Care follows the FHIR R5 QuestionnaireResponse resource as a concept model. The form, the answers, the author, and the submission time match that model. Care does not export a fully validated FHIR QuestionnaireResponse resource. ## Related -- Reference: [Questionnaire Response (technical)](../../references/clinical/questionnaire-response.mdx) -- Concept: [Questionnaire](../definitions/questionnaire.mdx) — the form definition being answered -- Concept: [Questionnaire Response Template](../definitions/questionnaire-response-template.mdx) — reusable pre-fill templates -- Concept: [Encounter](../clinical/encounter.mdx) — the visit a response is recorded in -- Concept: [Patient](../clinical/patient) — the record a response belongs to +- Flow: [View questionnaire responses](../../flows/clinical/questionnaire-response/view-questionnaire-responses.mdx) +- Flow: [Print a questionnaire response](../../flows/clinical/questionnaire-response/print-a-questionnaire-response.mdx) +- Flow: [Mark a response as entered in error](../../flows/clinical/questionnaire-response/mark-a-response-as-entered-in-error.mdx) +- Concept: [Patient](../../concepts/clinical/patient) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) +- Concept: [Condition](../../concepts/clinical/condition.mdx) +- Concept: [Allergy](../../concepts/clinical/allergy-intolerance.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/service-request.mdx b/versioned_docs/version-3.1/concepts/clinical/service-request.mdx index 5208c7aa..5cc66d62 100644 --- a/versioned_docs/version-3.1/concepts/clinical/service-request.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/service-request.mdx @@ -1,76 +1,96 @@ --- -sidebar_position: 8 +sidebar_position: 5 --- -# Service Request +# Clinical - Service Request -A **service request** is an order to do something for a patient — run a lab test, take an X-ray, book a counselling session, perform a procedure. It turns a clinician's "please do this" into a tracked item that another team can pick up and that later results can attach to. +## Definition -## What it represents +A **[service request](https://build.fhir.org/servicerequest.html)** in Care is a request for a service for a patient. The service is a diagnostic test, a procedure, or a referral. You create a service request inside an encounter. Care takes the patient from that encounter. Clinical staff use the service request to tell other staff what to do. The request also states where to do the service and how urgent it is. -In Care's FHIR-aligned model, a service request maps to the **ServiceRequest** resource. It captures: +You start a service request from the facility service catalogue. You select an **Activity Definition**. Care copies the title, the category, the code, the body site, the locations, and the healthcare service from that entry. -- **What is being asked for** — a coded service or procedure, an optional body site, and a free-text title -- **Why and how** — the category of work, the priority, and any notes or patient instructions -- **Where it sits in care** — the patient and encounter it was raised in, the facility, and optionally the service, locations, or clinician fulfilling it -- **Its standing** — an intent (firm order or mere proposal?) and a lifecycle status everyone can see +You work with service requests on the **Service Requests** tab of an encounter. You also see the requests of one facility location in the **Service Requests** list of that location. -The key thing to hold onto: a service request is the *order*, not the *result*. The specimen that gets collected, the diagnostic report that comes back, the observations that get recorded — those are separate records that each point back to the originating request. One request can spawn several of them. +## Key Attributes -## Intent — how binding is it? +| Components | What it captures | +| --- | --- | +| Title | The short name that identifies the request. Care copies it from the activity definition. | +| Status | The stage of the request. See [Status](#status). | +| Intent | How strong the request is. See [Intent](#intent). | +| Priority | How urgent the request is. See [Priority](#priority). | +| Category | The type of service that you request. Care copies it from the activity definition. See [Category](#category). | +| Code | The test or the procedure that the request asks for, for example a laboratory test or an imaging study. Care copies it from the activity definition. | +| Do Not Perform | A flag that tells staff not to do the requested service. | +| Note | Extra information for the staff who receive the request. | +| Occurrence | The date and time for the requested service. | +| Patient Instruction | The instructions for the patient about the requested service. | +| Body Site | The part of the body for the requested service. | +| Locations | The facility locations where staff do the requested service. | +| Healthcare Service | The entry in the facility service catalogue that does the work. Care copies it from the activity definition. | +| Requester | The facility member who makes the request. You can select only a member of the facility. | +| Tags | The labels that help you group and find service requests. | -Every request carries an **intent** that says how committed the order is, so the same record can represent anything from a tentative idea to a confirmed instruction: a `proposal` is a suggestion someone has put forward; a `plan` is part of an agreed plan of care; a `directive` is a standing instruction; an `order` is a firm request to actually carry the work out. Intent answers "is this real yet?" — distinct from status, which answers "where has it got to?" +### Status -## Category and priority +| Status | Description | +| --- | --- | +| Draft | You prepare the request. The request is not yet active. | +| Active | Staff can act on the request. | +| On Hold | Staff stop work on the request for now. | +| Entered in Error | Someone created the request by mistake. | +| Completed | Staff finished the requested service. | +| Revoked | Someone cancelled the request. | +| Ended | Care does not use this status. No action in Care sets it. | -Two coded fields route and rank the work. **Category** decides which team picks it up — `laboratory`, `imaging`, `counselling`, `surgical_procedure`, or `education`. **Priority** sets how soon — `routine`, `urgent`, `asap`, or `stat`. Together they let a busy department triage a queue of requests without reading every one in full. +Care creates a new request with the status Active. Care also sets the intent to Order and the priority to Routine. Completed, Revoked, and Entered in Error are final statuses. Care blocks all further actions on a request in a final status. You reach Completed with the **Mark as Complete** action. You reach Revoked with the **Mark as revoked** action. You reach Entered in Error with the **Mark as entered in error** action. -## Lifecycle +### Intent -A request always sits in exactly one status — there is deliberately no "unknown". The active states are on the left; the four on the right are terminal. +| Intent | Description | +| --- | --- | +| Proposal | Someone suggests the service. | +| Plan | Someone plans the service. | +| Directive | Someone gives a direction for the service. | +| Order | Someone orders the service. | -```text -draft → active → on_hold → completed - ↘ ended / revoked / entered_in_error -``` +### Priority -- **draft** — being written, not yet actionable -- **active** — live and ready to be worked on -- **on_hold** — paused for now, expected to resume -- **completed** — the work has been fulfilled -- **ended** — stopped before completion, with no intent to resume -- **revoked** — cancelled or withdrawn -- **entered_in_error** — created by mistake; kept for audit, treated as void +| Priority | Description | +| --- | --- | +| Routine | Staff do the service in the normal order of work. | +| Urgent | Staff do the service before routine work. | +| ASAP | Staff do the service as soon as possible. | +| STAT | Staff do the service immediately. | -## How it connects +### Category -A service request is the hub that ties an order to the rest of the record: +| Category | Description | +| --- | --- | +| Laboratory | A laboratory test. | +| Imaging | An imaging study. | +| Counselling | A counselling service. | +| Procedure | A surgical procedure. | +| Education | An education service for the patient. | -- It is always raised inside an **encounter**, and the patient is inherited from that encounter — you never set the patient directly. -- It can be created from an **activity definition**, a reusable template that supplies the category and the catalogue of valid service codes. -- Once work begins, a **specimen** may be collected against it, and a **diagnostic report** and its **observations** are produced for it — all linking back to this request. -- It can name the **healthcare service** that fulfils it and the **locations** within the facility where it applies, plus the **requester** who placed it. +### Specimens and Diagnostic Reports -## Permissions +A service request can have linked specimens and linked diagnostic reports. A specimen is a sample that staff collect for a test. A diagnostic report holds the results for the request. -Access to service requests is governed by these facility-scoped permissions. +## Permissions -| Permission | Description | System Roles | +| Permission | What it allows | Roles | | --- | --- | --- | -| `can_write_service_request` | Create, update, complete, cancel, and apply an activity definition to service requests within a facility | Facility Admin, Admin, Doctor, Nurse | -| `can_read_service_request` | List and view service requests within a facility | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist | -| `can_write_specimen` | Create a specimen against a service request | Facility Admin, Admin, Doctor, Nurse | - -Roles are granted through a user's facility, organization, or patient memberships, and permissions cascade down the organization tree — a role given high in the tree applies to the facilities beneath it. +| Can Write Service Request on Facility | Create, complete, and cancel a service request. | Facility Admin, Admin, Doctor, Nurse | +| Can Read Service Request | View a service request. | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, Pharmacist | ## Related -- Reference: [Service Request (technical)](../../references/clinical/service-request.mdx) -- Concept: [Encounter](../clinical/encounter.mdx) — the context every request is raised in -- Concept: [Activity Definition](../definitions/activity-definition.mdx) — the template a request can be built from -- Concept: [Specimen](../clinical/specimen.mdx) — collected to fulfil a request -- Concept: [Diagnostic Report](../clinical/diagnostic-report.mdx) — the result produced for a request - -## FHIR reference - -This concept aligns with the FHIR **ServiceRequest** resource. Care implements a minimal, opinionated subset and uses snake_case values for status, intent, and priority rather than FHIR's hyphenated codes. +- Flow: [Create a service request](../../flows/clinical/service-request/create-a-service-request.mdx) +- Flow: [View service requests](../../flows/clinical/service-request/view-service-requests.mdx) +- Flow: [Complete a service request](../../flows/clinical/service-request/complete-a-service-request.mdx) +- Flow: [Cancel a service request](../../flows/clinical/service-request/cancel-a-service-request.mdx) +- Concept: [Encounter](../../concepts/clinical/encounter.mdx) +- Concept: [Specimen](../../concepts/clinical/specimen.mdx) +- Concept: [Diagnostic Report](../../concepts/clinical/diagnostic-report.mdx) diff --git a/versioned_docs/version-3.1/concepts/clinical/specimen.mdx b/versioned_docs/version-3.1/concepts/clinical/specimen.mdx index c9fabf95..2720db48 100644 --- a/versioned_docs/version-3.1/concepts/clinical/specimen.mdx +++ b/versioned_docs/version-3.1/concepts/clinical/specimen.mdx @@ -1,64 +1,59 @@ --- -sidebar_position: 9 +sidebar_position: 6 --- -# Specimen +# Clinical - Specimen -A **specimen** is a physical sample — blood, tissue, a swab, urine — collected from a patient so a laboratory can analyse it. It is the bridge between a lab order and a result: the order asks for a test, the specimen is the material that gets tested, and the report carries back what the lab found. +## Definition -## What it represents +A **[specimen](https://build.fhir.org/specimen.html)** in Care is a biological sample that a user collects from a patient for testing. Care always creates a specimen as part of a service request. You cannot create a specimen on its own. The specimen answers a specimen requirement that the underlying activity or service definition sets on that request. Care takes the patient, the encounter, and the facility from the parent service request. -In Care's FHIR-aligned model, a specimen maps to the **Specimen** resource. It captures: +## Key Attributes -- **The material** — what kind of sample was collected and its condition on arrival at the lab -- **The collection** — who took it, when, by what method, from which body site, and the patient's fasting status -- **Its identity** — an accession identifier (the lab barcode) used to find the sample fast -- **Its links** — the patient it came from, the encounter it was collected in, and the order it fulfils +| Components | What it captures | +| --- | --- | +| Accession Identifier | The tracking number of the specimen. Care generates the number if you leave the field blank. | +| Status | The current state of the specimen. | +| Specimen Type | The kind of sample, for example blood, urine, or tissue. Care codes the type with SNOMED CT. | +| Collection | The collector, the collection date and time, the quantity and its unit, the collection method, the body site, and the fasting status. | +| Processing | The list of processing steps. Each step holds a processing method, a description, a performer, and a time. | +| Condition | The condition of the sample when the laboratory receives it. | +| Notes | Free text remarks about the specimen. | -The distinction worth holding onto: a specimen is neither the order nor the result. The order asks for work; the specimen is the tangible thing that work is performed on; the findings return separately through a diagnostic report. One order can yield several specimens, and a single specimen can pass through several processing steps before it is tested. +### Accession Identifier -## Lifecycle +The accession identifier tracks the specimen through collection and processing. Care shows the identifier as a QR code. To find a specimen, scan the QR code or enter the accession identifier. -A specimen sits in exactly one status as it moves from collection to testing. The first two are working states; the last three are terminal. +Note: The section where you identify the specimen has the title **Sample Identification**. The rest of the product uses the word "Specimen". -```text -draft → available → unavailable / unsatisfactory / entered_in_error -``` +### Processing -- **draft** — a Care-specific starting state for a record still being prepared -- **available** — present at the lab and suitable for testing -- **unavailable** — no longer available, having been consumed, lost, or discarded -- **unsatisfactory** — reached the lab but unfit to test (contaminated, too little), so a recollection is usually needed -- **entered_in_error** — created by mistake; kept for audit, treated as void +Each processing step records what a user did to the sample. After a diagnostic report exists for the parent service request, you can no longer change the processing step of the specimen. -## How it connects +### Status -A specimen is the pivot of the lab workflow, and almost everything about it is borrowed from the records around it: +| Status | Description | +| --- | --- | +| Draft | Care created the specimen against a specimen requirement. The collection details are not complete. This status is specific to Care and is not part of FHIR. | +| Available | The collection details are complete. The sample is ready for use. | +| Unavailable | The sample is not available for testing. | +| Unsatisfactory | The sample does not meet the quality that the test needs. | +| Entered in Error | A user created the specimen by mistake. | -- It is always collected from a **patient**, during an **encounter** that gives the sample its clinical context. -- It exists to fulfil a **service request** — the lab order. One order may produce several specimens, and that order is also what governs who may read or write the specimen. -- It can be shaped by a **specimen definition**, an optional template describing the expected container and preparation. -- Once tested, its results surface through a **diagnostic report**, closing the loop back to the clinician who placed the order. +A specimen starts in Draft. You fill in the collection details, and the status moves to Available. If you find a problem with the sample, you discard the specimen as Unavailable, Unsatisfactory, or Entered in Error. These three statuses are final. A discarded specimen does not return to Available. ## Permissions -Access to specimens is governed by two facility-scoped permissions. - -| Permission | Description | System Roles | +| Permission | What it allows | Roles | | --- | --- | --- | -| `can_read_specimen` | View a specimen record, including lookup by accession identifier | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Pharmacist | -| `can_write_specimen` | Update a specimen — record collection, processing, and status changes | Facility Admin, Admin, Doctor, Nurse | - -Both permissions are checked against the specimen's linked service request rather than the specimen alone. Roles are granted through a user's facility, organization, or patient memberships, and permissions cascade down the organization tree — a role given high in the tree applies to the facilities beneath it. +| Can Create Specimen on Facility | Create, update, collect, process, and discard a specimen. | Facility Admin, Admin, Doctor, Nurse | +| Can Read Specimen | View a specimen and the specimen history. | Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Pharmacist | ## Related -- Reference: [Specimen (technical)](../../references/clinical/specimen.mdx) -- Concept: [Service Request](../clinical/service-request.mdx) — the order a specimen fulfils -- Concept: [Specimen Definition](../definitions/specimen-definition.mdx) — the template a specimen can be derived from -- Concept: [Diagnostic Report](../clinical/diagnostic-report.mdx) — where a specimen's results surface -- Concept: [Patient](../clinical/patient) — the person every specimen belongs to - -## FHIR reference - -This concept aligns with the FHIR **Specimen** resource. Care implements an opinionated subset: the patient, encounter, and order links are set on creation as `subject_patient`, `subject_encounter`, and `request`, and the status set adds a Care-specific `draft` value not present in FHIR. +- Flow: [Collect a specimen](../../flows/clinical/specimen/collect-a-specimen.mdx) +- Flow: [Process a specimen](../../flows/clinical/specimen/process-a-specimen.mdx) +- Flow: [Discard a specimen](../../flows/clinical/specimen/discard-a-specimen.mdx) +- Flow: [View specimen history](../../flows/clinical/specimen/view-specimen-history.mdx) +- Concept: [Service Request](../../concepts/clinical/service-request.mdx) +- Concept: [Diagnostic Report](../../concepts/clinical/diagnostic-report.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/care-team/_category_.json b/versioned_docs/version-3.1/flows/clinical/care-team/_category_.json new file mode 100644 index 00000000..2302b05c --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/care-team/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Care Team", + "position": 11, + "key": "clinical-care-team-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/care-team/add-care-team-members.mdx b/versioned_docs/version-3.1/flows/clinical/care-team/add-care-team-members.mdx new file mode 100644 index 00000000..67409fb7 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/care-team/add-care-team-members.mdx @@ -0,0 +1,82 @@ +--- +sidebar_position: 1 +--- + +# Add care team members + +## Overview + +This flow describes how to add a person to the [care team](../../../concepts/clinical/care-team.mdx) of an encounter. You give each person a clinical role on the team. + +## Pre-requisites + +- The patient has an encounter at the facility, and you open that encounter. +- The person that you add is a user of a department in the facility. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter non clinical | Lets you change the care team of an encounter. Administrator, Doctor, Nurse, and Facility Administrator have this permission. | + +## Steps + +### 1. Open the care team sheet + +Open the Encounter page for the patient. + +Select **Encounter Actions**. Press Shift+E to open this menu. + +Select **Manage Care Team**. + +You can also select **Manage Care Team** on the side panel of the **Overview** tab. + +Care opens a sheet with the title **Manage Care Team**. If you cannot make changes, the title is **View Care Team**. + +### 2. Select the department + +Select the department that the person belongs to. + +### 3. Select the member + +Open **Select Member**. + +Select the person. Care lists only the users of the department that you selected. + +### 4. Select the clinical role + +Open **Select Role**. + +Select the clinical role of the person. + +Note: The list of roles comes from a clinical terminology set. The roles can differ between deployments. + +### 5. Add the member + +Select **Add**. + +Care shows the message "Member added successfully". + +If the person is already on the care team, Care shows the message "Member already added". Care does not add the person a second time. + +To add more people, do steps 2 to 5 again for each person. + +Note: Care saves the whole care team as one list with each change. + +## Expected Outcome + +- Care adds the person to the care team of the encounter with the clinical role that you selected. +- The care team list shows each member and their clinical role. + +## Related + +Concepts: + +- [Care Team](../../../concepts/clinical/care-team.mdx) +- [Encounter](../../../concepts/clinical/encounter.mdx) + +Flows: + +- [View the care team](./view-the-care-team.mdx) +- [Modify the care team](./modify-the-care-team.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/care-team/modify-the-care-team.mdx b/versioned_docs/version-3.1/flows/clinical/care-team/modify-the-care-team.mdx new file mode 100644 index 00000000..cd8d2401 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/care-team/modify-the-care-team.mdx @@ -0,0 +1,76 @@ +--- +sidebar_position: 3 +--- + +# Modify the care team + +## Overview + +This flow describes how to change the primary member of the [care team](../../../concepts/clinical/care-team.mdx), and how to remove a member from the care team. + +## Pre-requisites + +- The patient has an encounter at the facility, and you open that encounter. +- The care team has at least one member. +- If you want to change the primary member, the care team has two or more members. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter non clinical | Lets you change the primary member and remove a member. Administrator, Doctor, Nurse, and Facility Administrator have this permission. | + +## Steps + +### 1. Open the care team + +Open the Encounter page for the patient. + +Select **Encounter Actions**, then select **Manage Care Team**. Press Shift+E to open the encounter actions. + +You can also select **Manage Care Team** on the side panel of the **Overview** tab. + +### 2. Change the primary member + +Care always treats the first person in the list as the primary member. + +Find the member that you want at the top of the list. + +Select **Mark as Primary** on that member. + +Care moves that person to the top of the list. Care shows the message "Primary member updated". + +Note: Care asks for no confirmation for this action. + +### 3. Remove a member + +Find the member that you want to remove. + +Select **Remove** on that member. + +Care opens the **Confirm Removing Member** dialog. + +Select **Remove** again to confirm. + +Care shows the message "Member removed successfully". + +Note: Remove staff when they no longer look after the patient. This keeps the care team correct for the staff who read the encounter. + +## Expected Outcome + +- The person that you mark as primary is at the top of the care team list, and Care shows "Primary member updated". +- The member that you remove is no longer on the care team list, and Care shows "Member removed successfully". +- Care saves the full care team list with each change, not only the member that you change. + +## Related + +Concepts: + +- [Care Team](../../../concepts/clinical/care-team.mdx) +- [Encounter](../../../concepts/clinical/encounter.mdx) + +Flows: + +- [Add care team members](./add-care-team-members.mdx) +- [View the care team](./view-the-care-team.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/care-team/view-the-care-team.mdx b/versioned_docs/version-3.1/flows/clinical/care-team/view-the-care-team.mdx new file mode 100644 index 00000000..b7a7bd8b --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/care-team/view-the-care-team.mdx @@ -0,0 +1,57 @@ +--- +sidebar_position: 2 +--- + +# View the care team + +## Overview + +This flow describes how to see the members of the [care team](../../../concepts/clinical/care-team.mdx) for an encounter in Care. + +## Pre-requisites + +- The patient has an encounter at the facility, and you open that encounter. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read encounter | Lets you open the encounter and see the care team. | +| Update Encounter non clinical | Lets you change the care team. Administrator, Doctor, Nurse, and Facility Administrator have this permission. | + +## Steps + +### 1. Open the Encounter page + +Open the Encounter page for the patient. + +### 2. Open the care team + +Use one of these two options: + +- Select **Encounter Actions**, then select **Manage Care Team**. Press Shift+E to open the encounter actions. +- Select **Manage Care Team** on the side panel of the **Overview** tab. + +Note: If you can only read the team, Care shows the same sheet with the title **View Care Team**. Care hides the controls to add, remove, and reorder members. + +### 3. Review the members + +Care lists every member with the name and the clinical role. The member marked **Primary** appears first in the list. + +## Expected Outcome + +- Care shows the care team sheet for the encounter. +- The sheet lists each member with the name and the clinical role, and shows the **Primary** member first. + +## Related + +Concepts: + +- [Care Team](../../../concepts/clinical/care-team.mdx) +- [Encounter](../../../concepts/clinical/encounter.mdx) + +Flows: + +- [Add care team members](./add-care-team-members.mdx) +- [Modify the care team](./modify-the-care-team.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/consent/_category_.json b/versioned_docs/version-3.1/flows/clinical/consent/_category_.json new file mode 100644 index 00000000..2bebff49 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/consent/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Consent", + "position": 8, + "key": "clinical-consent-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/consent/record-a-consent.mdx b/versioned_docs/version-3.1/flows/clinical/consent/record-a-consent.mdx new file mode 100644 index 00000000..34cf5fd4 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/consent/record-a-consent.mdx @@ -0,0 +1,102 @@ +--- +sidebar_position: 1 +--- + +# Record a consent + +## Overview + +This flow describes how to record a [consent](../../../concepts/clinical/consent.mdx) against an encounter of a patient. You can also attach the signed consent form and other supporting documents. + +## Pre-requisites + +- The patient is registered in Care, and you open an encounter of that patient. +- You open the encounter from the facility, and the encounter is active. +- You have the permission listed below. Care hides the **Add Consent** button from the users who cannot write to the encounter. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter related clinical data | Lets you record a consent against an encounter. Admin, Doctor, Nurse, and Facility Admin have this permission. | + +## Steps + +### 1. Open the Consents tab + +1. Open the encounter of the patient. +2. Select the **Consents** tab. + +### 2. Start the consent form + +Select **Add Consent**. Care opens the **Add Consent** sheet. + +The sheet holds these fields. + +| Components | What it captures | +| --- | --- | +| Consent Given On | The date and time when the patient gives the consent. This field is mandatory. | +| Consent Valid From | The date and time from which the consent is valid. This field is optional. | +| Consent Valid Until | The date and time until which the consent is valid. This field is optional. | +| Consent Decision | The answer of the patient: **Permit** or **Deny**. | +| Category | The subject of the consent. | +| Status | The current state of the consent: Draft, Active, Inactive, Not Done, or Entered in Error. Care sets **Active** as the default value. | +| Note | Free text about the consent. This field is optional. | + +### 3. Enter the consent details + +1. Enter the date and time in **Consent Given On**. +2. Enter **Consent Valid From** and **Consent Valid Until** for a consent with a validity period. +3. Select **Permit** or **Deny** for **Consent Decision**. +4. Select the **Status** of the consent. +5. Enter a **Note** about the consent. + +### 4. Select the category + +Open the **Category** list. Care shows a short description under each option. + +| Category | Description | +| --- | --- | +| Research | Consent to take part in a research protocol and to share information. | +| Privacy Consent | Consent to collect, access, use, or share information. | +| Treatment | Consent to undergo a specific treatment. | +| Do Not Resuscitate | Consent to not receive CPR or resuscitation in a cardiac event. | +| Advance Directive | Consent that the patient gives before a possible need for medical treatment. | +| Advance Care Directive | Consent for the actions to take if the patient can no longer decide. | + +Select the category of the consent. + +Note: Care also holds a **Comfort Care** category, but this form has no option for it. You cannot select Comfort Care. This is a known gap in the product. + +### 5. Attach the supporting documents + +You can attach one or more files to the consent in the **Supporting Documents** section. + +1. Choose a file. Care accepts these file types: jpg, jpeg, png, and pdf. +2. Enter a name for the file. The name is mandatory. +3. Repeat these steps for each more file. + +Note: Care uploads the files after it saves the consent record. + +### 6. Save the consent + +Select **Save**. + +## Expected Outcome + +- Care shows the message "Consent created successfully". +- Care shows the new consent as a card on the **Consents** tab. +- Care uploads the attached files to the new consent. + +## Related + +Concepts: + +- [Consent](../../../concepts/clinical/consent.mdx) +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [View consents](./view-consents.mdx) +- [Update a consent](./update-a-consent.mdx) +- [Verify a consent](./verify-a-consent.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/consent/update-a-consent.mdx b/versioned_docs/version-3.1/flows/clinical/consent/update-a-consent.mdx new file mode 100644 index 00000000..c425c9e7 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/consent/update-a-consent.mdx @@ -0,0 +1,78 @@ +--- +sidebar_position: 3 +--- + +# Update a consent + +## Overview + +This flow describes how to change the status or the note of an existing [consent](../../../concepts/clinical/consent.mdx) in Care. + +## Pre-requisites + +- A member of staff recorded the consent against an encounter of the patient. +- You open the encounter from the facility, and the encounter is active. Care hides the **Edit** button on a completed or cancelled encounter. +- You have the permission listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter related clinical data | Lets you change the clinical data of an encounter, which includes consents. Admin, Doctor, Nurse, and Facility Admin have this permission. | + +## Steps + +### 1. Open the consent + +1. Open the encounter. +2. Select the **Consents** tab. +3. Select **See Details** on the consent that you want to change. Care opens the consent record. + +### 2. Start the edit form + +Select **Edit**. Care opens the **Edit Consent** form. + +The form keeps the values that you gave when you recorded the consent. You can change these fields: + +| Components | What it captures | +| --- | --- | +| Status | The current state of the consent: Draft, Active, Inactive, Not Done, or Entered in Error. | +| Note | Free text about the consent. | + +The form does not show these fields. Care keeps the values that you gave at creation: + +- Consent Decision +- Category +- Consent Given On +- Consent Valid From and Consent Valid Until + +Note: The edit form has no file upload. To attach one more file, use the **Supporting Documents** section of the consent record. + +### 3. Change the status or the note + +1. Select the new **Status**. +2. Enter or change the **Note**. + +Note: Care accepts a change from any status to any other status. Care does not ask you to confirm the change. + +### 4. Save the consent + +Select **Save**. + +## Expected Outcome + +- Care shows the message "Consent updated successfully". +- Care refreshes the consent record and the **Consents** tab. +- The consent shows the new status and the new note. + +## Related + +Concepts: + +- [Consent](../../../concepts/clinical/consent.mdx) + +Flows: + +- [Record a consent](./record-a-consent.mdx) +- [View consents](./view-consents.mdx) +- [Verify a consent](./verify-a-consent.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/consent/verify-a-consent.mdx b/versioned_docs/version-3.1/flows/clinical/consent/verify-a-consent.mdx new file mode 100644 index 00000000..662ad102 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/consent/verify-a-consent.mdx @@ -0,0 +1,68 @@ +--- +sidebar_position: 4 +--- + +# Verify a consent + +## Overview + +This flow describes the verification of a [consent](../../../concepts/clinical/consent.mdx). A verification is a second confirmation of a consent that a member of staff recorded for a patient. + +Note: The current version of Care has no screen for consent verification. You cannot add, view, or remove a verification from the web application. The steps below record what the system holds today. Review this flow again after the product adds the screen. + +## Pre-requisites + +- The patient has an encounter at the facility, and a member of staff recorded a consent for that encounter. +- You did not verify this consent before. Care refuses a second verification from the same user. +- You have the permission listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter related clinical data | Lets you add a verification to a consent, and remove a verification from a consent. | + +The Admin, Doctor, Nurse, and Facility Admin roles hold this permission. + +## Steps + +### 1. Open the consent + +Open the encounter of the patient. Select the **Consents** tab. Select **See Details** on the consent that you want to verify. + +### 2. Add the verification + +The consent record has no verification section, so you cannot add a verification here. + +When you add a verification, Care holds this information: + +| Component | What it captures | +| --- | --- | +| Verification Type | The source of the confirmation: **Family** for a family member or a representative, or **Validation** for the patient. | +| Verified by | The name of the user who confirms the consent. | +| Verification date | The date and time of the confirmation. | + +Care accepts one verification for each user on one consent. A second verification from the same user gives an error. + +### 3. Remove the verification + +The consent record has no verification section, so you cannot remove a verification here. + +Care removes only a verification that the same user added. + +## Expected Outcome + +- Care holds the verification type, the name of the verifier, and the date and time of the verification. +- Care does not show this information on any screen in the current version. + +## Related + +Concepts: + +- [Consent](../../../concepts/clinical/consent.mdx) + +Flows: + +- [Record a consent](./record-a-consent.mdx) +- [View consents](./view-consents.mdx) +- [Update a consent](./update-a-consent.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/consent/view-consents.mdx b/versioned_docs/version-3.1/flows/clinical/consent/view-consents.mdx new file mode 100644 index 00000000..8807a6ae --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/consent/view-consents.mdx @@ -0,0 +1,69 @@ +--- +sidebar_position: 2 +--- + +# View consents + +## Overview + +This flow describes how to view the [consents](../../../concepts/clinical/consent.mdx) recorded for an encounter. You can review each consent as a card, or open its full record. + +## Pre-requisites + +- The patient is registered in Care, and you open an encounter of that patient. +- A member of staff recorded at least one consent for the encounter. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can view clinical data about patients | Lets you view the consents of any patient you have access to. | +| Can Read encounter related clinical data | Lets you view the consents of the encounters you have access to. | + +## Steps + +### 1. Open the Consents tab + +Open the encounter of the patient. Select the **Consents** tab. Care shows each consent as a card. + +### 2. Review the consent cards + +Each card shows the details below. + +| Component | What it shows | +| --- | --- | +| Category badge | The category of the consent. | +| Expired badge | Care shows this badge when the validity period has passed. | +| Supporting documents | The names of the attached files. Care shows "No files attached" when the consent has no files. | +| Decision badge | The decision of the consent: **Permitted** or **Denied**. | +| Status badge | The status of the consent. | +| Consent Given On | The date and time when the patient gave the consent. | +| Valid Period | The period for which the consent stays valid. | + +### 3. Search for a consent + +Enter a file name in the search box above the cards. Care shows only the consents that have an attached file with that name. + +### 4. Open the full consent record + +Select **See Details** on the card. Care opens the consent record. The record shows the supporting documents, the note, and a **Consent Details** card with the category, the date, the valid period, the decision, and the status. + +You can view or download each attached file from this record. + +## Expected Outcome + +- You see all the consents of the encounter as cards. +- You see the full record of the consent that you select. + +## Related + +Concepts: + +- [Consent](../../../concepts/clinical/consent.mdx) + +Flows: + +- [Record a consent](./record-a-consent.mdx) +- [Update a consent](./update-a-consent.mdx) +- [Verify a consent](./verify-a-consent.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/diagnostic-report/_category_.json b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/_category_.json new file mode 100644 index 00000000..d1624919 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Diagnostic Report", + "position": 7, + "key": "clinical-diagnostic-report-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/diagnostic-report/enter-diagnostic-report-results.mdx b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/enter-diagnostic-report-results.mdx new file mode 100644 index 00000000..9807c7ed --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/enter-diagnostic-report-results.mdx @@ -0,0 +1,88 @@ +--- +sidebar_position: 1 +--- + +# Enter diagnostic report results + +## Overview + +This flow describes how to create a [diagnostic report](../../../concepts/clinical/diagnostic-report.mdx) for a service request. You record the result of each observation, and you set the report status. + +## Pre-requisites + +- The patient has a service request at the facility, and you record the diagnostic report for that service request. +- If the service request needs a specimen, the laboratory staff collect and process the specimen first. +- If an external laboratory sends the result as a document, you have that file on your device. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Create Diagnostic Report on Facility | Lets you create a diagnostic report and enter its observations. Facility Admin, Admin, Doctor, and Nurse have this permission. | + +## Steps + +### 1. Open the service request + +Open the detail page of the service request. The page shows the specimen section, the processing section, and the diagnostic report form together. + +### 2. Start the diagnostic report + +Open the diagnostic report form on the service request page. + +| Components | What it captures | +| --- | --- | +| Category | The type of diagnostic service that produces the result. | +| Code | The test or panel that the report covers. | + +### 3. Enter the observation values + +The form shows one row for each observation that the service request requires. + +Enter the values for each row. + +| Components | What it captures | +| --- | --- | +| Value | The measured result of the observation. | +| Unit | The unit of measurement for the value. | +| Interpretation | The reading of the value, such as High, Low, or Normal. Enter it where it applies. | + +### 4. Attach a file + +Attach a file to the report when an external laboratory sends the result as a document. + +Choose a file from your device, or capture an image with the camera. + +### 5. Set the status + +A new report starts with the status Registered. + +Set the status to Preliminary or Partial when you record the first results. + +Set the status to Final when all results are complete. + +Note: You cannot change the observation rows after you set the status to Final. + +### 6. Save the report + +Save the diagnostic report. + +## Expected Outcome + +- Care creates the diagnostic report for the service request. +- The report shows the observation values, the units, and the interpretations that you entered. +- The report shows the status that you set. + +## Related + +Concepts: + +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [View a diagnostic report](./view-a-diagnostic-report.mdx) +- [Update a diagnostic report](./update-a-diagnostic-report.mdx) +- [Print a diagnostic report](./print-a-diagnostic-report.mdx) +- [Create a service request](../../../flows/clinical/service-request/create-a-service-request.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/diagnostic-report/print-a-diagnostic-report.mdx b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/print-a-diagnostic-report.mdx new file mode 100644 index 00000000..64cdcbb8 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/print-a-diagnostic-report.mdx @@ -0,0 +1,65 @@ +--- +sidebar_position: 4 +--- + +# Print a diagnostic report + +## Overview + +This flow describes how to open the print-formatted version of a [diagnostic report](../../../concepts/clinical/diagnostic-report.mdx) in Care and print it. + +## Pre-requisites + +- A user entered the diagnostic report in Care, and you print that report. +- You are a member of the facility that holds the report. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read Diagnostic Report | Lets you open a diagnostic report and its print-formatted version. Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, and Volunteer hold this permission. | + +## Steps + +### 1. Open the diagnostic report + +Open the detail view of the diagnostic report. You can also start from the report's entry in the diagnostic reports list. + +### 2. Open the print-formatted version + +Select the print action for the report. Care opens the print-formatted version of the report. + +### 3. Check the report content + +Check the print-formatted version before you print it. The print-formatted version shows the following content: + +| Content | What it shows | +| --- | --- | +| Category | The category of the diagnostic report. | +| Code | The code of the diagnostic report. | +| Conclusion | The clinical conclusion for the report. | +| Note | The notes recorded on the report. | +| Results | The table of observation results for the report. | +| Requester | The user who requested the report. | + +### 4. Print the report + +Print the print-formatted version with the print command of your browser. + +## Expected Outcome + +- Care shows the print-formatted version of the diagnostic report. +- The printed report shows the category, code, conclusion, note, observation results, and the requester. + +## Related + +Concepts: + +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [Enter diagnostic report results](./enter-diagnostic-report-results.mdx) +- [View a diagnostic report](./view-a-diagnostic-report.mdx) +- [Update a diagnostic report](./update-a-diagnostic-report.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/diagnostic-report/update-a-diagnostic-report.mdx b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/update-a-diagnostic-report.mdx new file mode 100644 index 00000000..667811d9 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/update-a-diagnostic-report.mdx @@ -0,0 +1,69 @@ +--- +sidebar_position: 3 +--- + +# Update a diagnostic report + +## Overview + +This flow describes how to change the details of a [diagnostic report](../../../concepts/clinical/diagnostic-report.mdx) in Care. You update the report from its detail view. + +## Pre-requisites + +- A user entered the diagnostic report in Care, and you update that report. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Create Diagnostic Report on Facility | Lets you create and update diagnostic reports at the facility. Facility Admin, Admin, Doctor, and Nurse users have this permission. | + +## Steps + +### 1. Open the diagnostic report + +Open the detail view of the diagnostic report that you want to update. + +### 2. Change the report details + +Change the fields that you want to update. + +| Components | What it captures | +| --- | --- | +| Status | The progress of the report: Registered, Preliminary, Partial, or Final. | +| Category | The clinical service that produced the report. | +| Code | The test or panel that the report covers. | +| Note | Extra remarks about the report. | +| Conclusion | The interpretation of the results. | + +You can change these fields at any time. Care does not enforce an order of status changes. If you have the permission, you can set the status directly to Registered, Preliminary, Partial, or Final. + +Note: You cannot change the service request that the report links to. Care sets this link when you create the report. + +### 3. Change the observation results + +If the status of the report is not Final, add or change the observation results. + +If the status of the report is Final, Care locks the results. Care rejects every change to the results of a Final report. + +### 4. Save the report + +Save your changes. + +## Expected Outcome + +- Care stores the new details of the diagnostic report. +- The detail view shows the updated status, category, code, note, and conclusion. + +## Related + +Concepts: + +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [Enter diagnostic report results](./enter-diagnostic-report-results.mdx) +- [View a diagnostic report](./view-a-diagnostic-report.mdx) +- [Print a diagnostic report](./print-a-diagnostic-report.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/diagnostic-report/view-a-diagnostic-report.mdx b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/view-a-diagnostic-report.mdx new file mode 100644 index 00000000..2da08768 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/diagnostic-report/view-a-diagnostic-report.mdx @@ -0,0 +1,81 @@ +--- +sidebar_position: 2 +--- + +# View a diagnostic report + +## Overview + +This flow describes how to open and read a [diagnostic report](../../../concepts/clinical/diagnostic-report.mdx) for an encounter in Care. + +## Pre-requisites + +- The patient has an encounter at the facility, and you view the reports for that encounter. +- A user entered a diagnostic report for the encounter. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read Diagnostic Report | Lets you open and read diagnostic reports. Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, and Volunteer have this permission. | + +## Steps + +### 1. Open the Diagnostic Reports tab + +Open the encounter of the patient. + +Select the **Diagnostic Reports** tab. + +Care shows a two-panel layout. The left panel lists the diagnostic reports of the encounter. The right panel shows the detail of the selected report. + +### 2. Find the report in the list + +Read the entries in the left panel. Each entry shows the information in the table below. + +| Component | What it shows | +| --- | --- | +| Title | The title of the related service request | +| Created date | The date when Care created the report | +| Status badge | The status of the report: Registered, Preliminary, Partial, or Final | +| Category | The category of the report | + +### 3. Select the report + +Click the entry of the report that you want to read. + +Care shows the full detail of the report in the right panel. + +### 4. Read the report detail + +Read the detail of the report in the right panel. The panel shows the information in the table below. + +| Component | What it shows | +| --- | --- | +| Status | The status of the report | +| Category | The category of the report | +| Code | The code of the report | +| Conclusion | The conclusion of the report | +| Note | The note that the user recorded on the report | +| Results | The observation results of the report, in a results table | +| Requester | The user who requested the report, taken from the related service request | +| Files | The files that a user attached to the report | + +## Expected Outcome + +- Care shows the selected diagnostic report of the encounter in the right panel. +- The panel shows the status, the category, the code, the conclusion, and the note. +- The panel also shows the observation results, the requester, and the attached files. + +## Related + +Concepts: + +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [Enter diagnostic report results](./enter-diagnostic-report-results.mdx) +- [Update a diagnostic report](./update-a-diagnostic-report.mdx) +- [Print a diagnostic report](./print-a-diagnostic-report.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/files/_category_.json b/versioned_docs/version-3.1/flows/clinical/files/_category_.json new file mode 100644 index 00000000..ae8717f3 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Files", + "position": 9, + "key": "clinical-files-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/files/archive-a-file.mdx b/versioned_docs/version-3.1/flows/clinical/files/archive-a-file.mdx new file mode 100644 index 00000000..bcf66ed0 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/archive-a-file.mdx @@ -0,0 +1,62 @@ +--- +sidebar_position: 4 +--- + +# Archive a file + +## Overview + +This flow describes how to archive a [file](../../../concepts/clinical/files.mdx) in Care. Care has no permanent delete for files. Archiving is the only way to remove a file from the active list. + +Note: Archiving is irreversible. You cannot restore an archived file. + +## Pre-requisites + +- The file is uploaded to the patient or the encounter that you work with. +- You know the reason for the archive. Care asks you to type the reason. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Write access to the patient or the encounter that the file belongs to | Lets you archive the file. | + +## Steps + +### 1. Open the file action menu + +Go to the file that you want to archive. + +Click the **...** menu for the file. + +### 2. Select Archive + +Select **Archive**. + +Care opens a confirmation dialog. The dialog warns you that this action is irreversible. + +### 3. Enter the reason + +Enter the reason for the archive in the text box. + +Confirm the archive. + +## Expected Outcome + +- Care greys out the file in the list and adds an **Archived** badge. +- Care hides the file from the default list. To see the file again, set the filter on the **Files** tab to **Archived**. +- For an archived file, the **View** option opens the details dialog. The dialog shows who uploaded the file and when. The dialog also shows who archived the file, when, and why. + +## Related + +Concepts: + +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [Upload a file](./upload-a-file.mdx) +- [View or preview a file](./view-or-preview-a-file.mdx) +- [Rename a file](./rename-a-file.mdx) +- [Download a file](./download-a-file.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/files/download-a-file.mdx b/versioned_docs/version-3.1/flows/clinical/files/download-a-file.mdx new file mode 100644 index 00000000..4cf0c7aa --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/download-a-file.mdx @@ -0,0 +1,54 @@ +--- +sidebar_position: 5 +--- + +# Download a file + +## Overview + +This flow describes how to download a [file](../../../concepts/clinical/files.mdx) from Care to your device. + +## Pre-requisites + +- The file is uploaded to the patient or the encounter that you work with. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| The permission to view clinical data for the patient or the encounter that the file belongs to | Lets you view and download the file. | + +Note: Download is available to every user who can view the file. Unlike **Rename** and **Archive**, download does not need write access to the patient or the encounter. + +## Steps + +### 1. Open the file action menu + +Find the file in the **Files** tab. Click the **...** menu for the file. + +### 2. Select Download + +Select **Download**. Care fetches the file. Care saves the file to your device. + +### 3. Follow the progress messages + +Care shows a message when the download starts. Care shows a second message when the download completes. If the download does not succeed, Care shows a failure message. + +## Expected Outcome + +- Care saves the file to your device. +- Care shows a download completed message. + +## Related + +Concepts: + +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [Upload a file](./upload-a-file.mdx) +- [View or preview a file](./view-or-preview-a-file.mdx) +- [Rename a file](./rename-a-file.mdx) +- [Archive a file](./archive-a-file.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/files/rename-a-file.mdx b/versioned_docs/version-3.1/flows/clinical/files/rename-a-file.mdx new file mode 100644 index 00000000..925538da --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/rename-a-file.mdx @@ -0,0 +1,59 @@ +--- +sidebar_position: 3 +--- + +# Rename a file + +## Overview + +This flow describes how to change the name of a [file](../../../concepts/clinical/files.mdx) in Care. + +## Pre-requisites + +- The file is uploaded to the patient or the encounter in Care. +- You can edit files for that patient or that encounter. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Write access to the patient or the encounter that the file belongs to | Lets you rename the file. Care hides the **Rename** option from users with read-only access. | + +## Steps + +### 1. Open the file action menu + +Go to the file that you want to rename. + +Click the **...** menu for the file. + +### 2. Select Rename + +Select **Rename**. + +Care opens a dialog with a text box. The text box shows the current name of the file. + +### 3. Enter the new name + +Enter the new name in the text box. + +Confirm the change. + +## Expected Outcome + +- Care updates the name of the file. +- Care shows a success message. + +## Related + +Concepts: + +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [Upload a file](./upload-a-file.mdx) +- [View or preview a file](./view-or-preview-a-file.mdx) +- [Archive a file](./archive-a-file.mdx) +- [Download a file](./download-a-file.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/files/upload-a-file.mdx b/versioned_docs/version-3.1/flows/clinical/files/upload-a-file.mdx new file mode 100644 index 00000000..c758abfb --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/upload-a-file.mdx @@ -0,0 +1,78 @@ +--- +sidebar_position: 1 +--- + +# Upload a file + +## Overview + +This flow describes how to upload a [file](../../../concepts/clinical/files.mdx) to a patient or to an encounter in Care. You can add a file from your device, from your camera, or from an audio recording. + +## Pre-requisites + +- The patient is registered in Care, and you attach the file to that patient. +- If you attach the file to an encounter, the encounter is not inactive. +- The file is not larger than 100 MB. +- The file is an image, a video, an audio file, a text file, an office document, or a PDF. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Write access to the patient | Lets you upload a file to the patient. | +| Write access to the encounter | Lets you upload a file to the encounter. | + +## Steps + +### 1. Open the Files tab + +Open the patient or the encounter that the file belongs to. + +Select the **Files** tab. + +### 2. Add the file + +Select **Add Files**. Care shows a dropdown with three ways to add a file. + +| Option | What it does | +| --- | --- | +| Upload From Device | Opens the file picker of your device. Select one or more files. | +| Open Camera | Opens a full-screen camera view. Take a photo. Keep the photo or take it again. | +| Record Audio | Opens an audio recorder with a live timer. Record your voice. Save the recording. | + +To add a photo, select **Open Camera**. You can switch between the front camera, the back camera, and another connected camera. Select the capture control to take the photo. Select the retake control to take the photo again. + +To add a recording, select **Record Audio**. Select **Stop** to end the recording. Listen to the preview. Save the recording. Care saves the recording as an mp3 file. Care gives the file a name with a timestamp. + +### 3. Name the files + +Care opens the upload dialog after you add one or more files. + +Enter a name for each file. A name is required for every file. + +Note: If you add two or more images, Care shows the **Combine Files To PDF** option. Select this option to merge the images into one PDF. + +### 4. Upload the files + +Select **Upload**. + +Care shows a progress bar for each file. + +## Expected Outcome + +- Care shows a success message after the upload ends. +- The files appear in the **Files** tab of the patient or the encounter. + +## Related + +Concepts: + +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [View or preview a file](./view-or-preview-a-file.mdx) +- [Rename a file](./rename-a-file.mdx) +- [Archive a file](./archive-a-file.mdx) +- [Download a file](./download-a-file.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/files/view-or-preview-a-file.mdx b/versioned_docs/version-3.1/flows/clinical/files/view-or-preview-a-file.mdx new file mode 100644 index 00000000..87a26bcc --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/files/view-or-preview-a-file.mdx @@ -0,0 +1,89 @@ +--- +sidebar_position: 2 +--- + +# View or preview a file + +## Overview + +This flow describes how to find a file in the **Files** tab and open its preview in Care. Some file types open a preview. Other file types need a download. + +## Pre-requisites + +- The file is uploaded to the patient or the encounter that you work with. +- If you look for an archived file, set the filter to **Archived**. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| The permission to view clinical data for the patient or the encounter that the file belongs to | Lets you list, preview, and open the files of that patient or encounter. | + +## Steps + +### 1. Open the Files tab + +Open the patient or the encounter that holds the file. Select the **Files** tab. On a large screen, Care shows the files in a table. The table has these columns. + +| Column | What it shows | +| --- | --- | +| File Name | The name of the file | +| File Type | The type of the file | +| Date | The date of the file | +| Shared By | The person who uploaded the file | +| Actions menu | The actions that you can do on the file | + +On a small screen, Care shows each file as a card. + +### 2. Filter the list + +Use the filter to select **Active** files or **Archived** files. Care shows only the files that match the filter. + +### 3. Open the preview + +Find the file in the list. Open the actions menu for the file. Select **View**. Care opens the preview of the file. + +Note: Care shows the **View** option only for a file that it can preview. + +### 4. Work with the preview + +The controls in the preview depend on the type of the file. + +| File type | What you can do | +| --- | --- | +| Image | Pinch, zoom, and pan the image | +| PDF | Read the file in the preview. Select **Print**, or select **Open in browser** | +| Video | Play the video in the preview | +| HTML | Read the page in a sandboxed frame | + +Note: A .mov video does not play in a browser other than Safari. For a .mov video, Care offers a download instead. + +For an audio file, Care shows a **Play** button. Select **Play**. Care opens the audio player. + +### 5. Step to another file + +If the patient or the encounter has more than one file, you can step through the files in the preview. Press the Left arrow key for the previous file. Press the Right arrow key for the next file. + +### 6. Open a file that has no preview + +Care cannot preview some file types, for example a Word document or an Excel document. For these files, Care shows a message that it cannot preview the file. Download the file, then open it on your device. + +## Expected Outcome + +- Care shows the content of the file in the preview. +- You step between the files of the patient or the encounter with the arrow keys. +- For a file that has no preview, Care tells you to download the file. + +## Related + +Concepts: + +- [Files](../../../concepts/clinical/files.mdx) + +Flows: + +- [Upload a file](./upload-a-file.mdx) +- [Rename a file](./rename-a-file.mdx) +- [Archive a file](./archive-a-file.mdx) +- [Download a file](./download-a-file.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/notes/_category_.json b/versioned_docs/version-3.1/flows/clinical/notes/_category_.json new file mode 100644 index 00000000..a80eb7b1 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/notes/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Notes", + "position": 12, + "key": "clinical-notes-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/notes/find-discussions.mdx b/versioned_docs/version-3.1/flows/clinical/notes/find-discussions.mdx new file mode 100644 index 00000000..3d8fc3aa --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/notes/find-discussions.mdx @@ -0,0 +1,84 @@ +--- +sidebar_position: 3 +--- + +# Find discussions for a patient or an encounter + +## Overview + +This flow describes how to find [Clinical Notes](../../../concepts/clinical/notes.mdx) discussions in Care. Care keeps two separate lists. One list belongs to the encounter. The other list belongs to the patient alone. + + + +[Watch the demo](/media/clinical/notes/3.%20Find%20discussions%20for%20a%20patient%20or%20an%20encounter.mp4) — the encounter Notes tab's discussion list, then the separate patient profile Notes tab list. + +Note: The two lists never overlap. A discussion appears in one list only. + +## Pre-requisites + +- The patient is registered in Care. +- If you look for encounter discussions, the patient has an encounter at the facility. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read encounter related clinical data | See the discussions of an encounter. Doctor, Nurse, Admin, and Facility Admin hold this permission. | +| Can view clinical data about patients | See the discussions of a patient. Staff, Doctor, Nurse, Admin, and Facility Admin hold this permission. | + +## Steps + +### 1. Find the discussions of an encounter + +1. Open the encounter. +2. Select the **Notes** tab. You can also press `g` and then `n`. +3. Read the list of discussions. + +The list shows only the discussions that belong to this encounter. Discussions that belong to the patient alone do not appear here. + +Note: The **Notes** tab appears only if you can read clinical data for the patient or for the encounter. + +### 2. Find the discussions of a patient + +1. Open the patient profile. +2. Select the **Notes** tab. +3. Read the list of discussions. + +The list shows only the discussions that belong to the patient and to no encounter. Discussions that belong to an encounter do not appear here. + +### 3. Open a discussion + +1. Read the titles in the list. Care shows no search box and no filter for discussions. +2. Select a discussion. Care shows the messages of that discussion. + +Care shows the most recent discussion first. + +Note: On a small screen, select **Threads** at the bottom of the screen to open the list of discussions. + +If the list holds no discussion, Care shows "No discussions yet". + +### 4. Find the discussions of another encounter + +Each encounter keeps its own discussions. + +1. Open the other encounter. +2. Select the **Notes** tab. +3. Read the list of discussions. + +## Expected Outcome + +- You see the discussions of the encounter in the **Notes** tab of that encounter. +- You see the discussions of the patient in the **Notes** tab of the patient profile. +- You read the messages of the discussion that you select. + +## Related + +Concepts: + +- [Clinical Notes](../../../concepts/clinical/notes.mdx) + +Flows: + +- [Start a discussion](./start-a-discussion.mdx) +- [Post a message to a discussion](./post-a-message.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/notes/post-a-message.mdx b/versioned_docs/version-3.1/flows/clinical/notes/post-a-message.mdx new file mode 100644 index 00000000..642e0811 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/notes/post-a-message.mdx @@ -0,0 +1,85 @@ +--- +sidebar_position: 2 +--- + +# Post a message to a discussion + +## Overview + +This flow describes how you select a discussion in [Clinical Notes](../../../concepts/clinical/notes.mdx), read its messages, and post a new message. The screen is the same in the encounter Notes tab and in the patient profile Notes tab. + + + +[Watch the demo](/media/clinical/notes/2.%20Post%20a%20message%20to%20a%20discussion.mp4) — selecting a discussion and posting a message in the encounter Notes tab. + +## Pre-requisites + +- Someone started a discussion in the list that you look at. If the list holds no discussion, [start a discussion](./start-a-discussion.mdx) first. +- If you post in an encounter discussion, the encounter is open. Care treats an encounter as closed when its status is Completed, Cancelled, Discontinued, or Entered in error. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read encounter related clinical data | Read the messages in an encounter discussion. Doctor, Nurse, Admin, and Facility Admin hold this permission. | +| Update Encounter related clinical data | Post a message in an encounter discussion. Doctor, Nurse, Admin, and Facility Admin hold this permission. | +| Can view clinical data about patients | Read the messages in a patient discussion. Staff, Doctor, Nurse, Admin, and Facility Admin hold this permission. | +| Can Update a Patient's data | Post a message in a patient discussion. Staff, Doctor, Nurse, Administrator, Admin, and Facility Admin hold this permission. | + +## Steps + +### 1. Open the Notes tab + +Go to the **Notes** tab of the encounter or of the patient profile. In an encounter, press `g` and then `n` to go to the Notes tab. + +### 2. Select a discussion + +Select a discussion in the list on the left. On a small screen, select **Threads** at the bottom of the screen. Then select the discussion. + +Care opens the most recent discussion if you select none. + +Before you select a discussion, the screen shows "Welcome to Discussions" and "Start a new discussion or select an existing thread to begin messaging". The heading area shows "Select or create a thread to start messaging". + +The heading of the discussion shows how many people took part. It also shows how many messages the discussion holds. + +### 3. Read the messages + +Read the messages in the discussion. The newest message is at the bottom. + +Each message shows the author's picture and name. Each message also shows how long ago the author sent it. + +Point at the time to see the full date and time. Select the author's picture to open that user's profile. + +Care loads older messages while you scroll up. Care loads 20 messages at a time. + +### 4. Type your message + +Type in the box with the placeholder "Type your message...". The box gets taller as you type more lines. + +You can format the text with Markdown. Care shows the formatted result. + +Note: Care does not support file attachments. Care does not support mentions of other users. + +### 5. Send the message + +Select the send button. On a computer, you can also press `Shift` and `Enter` together to send. On a touch screen, use the send button. + +Note: If Care cannot send the message, Care shows no error. Look at the discussion to make sure that your message is there. + +## Expected Outcome + +- Care adds your message at the bottom of the discussion. +- Care moves the view to your new message. +- Care shows no way to delete a message. + +## Related + +Concepts: + +- [Clinical Notes](../../../concepts/clinical/notes.mdx) + +Flows: + +- [Start a discussion](./start-a-discussion.mdx) +- [Find discussions for a patient or an encounter](./find-discussions.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/notes/start-a-discussion.mdx b/versioned_docs/version-3.1/flows/clinical/notes/start-a-discussion.mdx new file mode 100644 index 00000000..b75056c0 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/notes/start-a-discussion.mdx @@ -0,0 +1,96 @@ +--- +sidebar_position: 1 +--- + +# Start a discussion + +## Overview + + + +[Watch the demo](/media/clinical/notes/1.%20Start%20a%20discussion.mp4) — starting a discussion from the encounter Notes tab. + +This flow describes how to start a new discussion in [Clinical Notes](../../../concepts/clinical/notes.mdx). A discussion groups related messages under one title. + +You can start a discussion in two contexts. A discussion that you start in an encounter belongs to that encounter. A discussion that you start on the patient profile belongs to the patient and to no encounter. + +## Pre-requisites + +- The patient is registered in Care. +- If you start the discussion in an encounter, the encounter is open. You cannot start a discussion in a closed encounter. Care treats an encounter as closed when its status is Completed, Cancelled, Discontinued, or Entered in error. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Update Encounter related clinical data | Lets you start a discussion inside an encounter. Doctor, Nurse, Admin, and Facility Admin hold this permission. | +| Can Update a Patient's data | Lets you start a discussion on the patient profile. Staff, Doctor, Nurse, Administrator, Admin, and Facility Admin hold this permission. | + +## Steps + +### 1. Go to the Notes tab + +Choose the context for the new discussion. + +- For an encounter discussion, open the encounter. Go to the **Notes** tab. Keyboard shortcut: press `g`, then press `n`. +- For a patient discussion, open the patient profile. Go to the **Notes** tab. + +Note: The two lists never overlap. A discussion that you start in an encounter does not show on the patient profile. A discussion that you start on the patient profile does not show in the encounter. + +### 2. Open the Start New Discussion dialog + +Select **New** above the discussion list. On a small screen, select **New Thread** at the bottom of the screen. + +If the list holds no discussion yet, you can also select **Start New Discussion** in the middle of the screen. + +Care opens the **Start New Discussion** dialog. Select the information icon next to the title to read this note: "Create a new discussion thread to organize your conversation topics." + +### 3. Enter the discussion title + +The dialog shows "Choose a template or enter a custom title". + +Select one of the suggested titles, or type your own title in the box with the placeholder "Enter discussion title...". + +The dialog suggests these titles: + +- Treatment Plan +- Medication Notes +- Care Coordination +- General Notes +- Patient History +- Referral Notes +- Lab Results Discussion + +Care removes a suggested title from the list when a discussion in this list already uses that title. After all suggestions are used, the dialog shows "Please enter a custom title for thread". + +Note: A title holds a maximum of 255 characters. + +Note: Two discussions in the same list cannot share a title. If the title is already in use, Care shows "Thread with this title already exists". Care does not create the discussion. + +### 4. Create the discussion + +Select **Create**. The **Create** button stays unavailable while the title box is empty. + +To stop without a new discussion, select **Cancel**. + +If Care cannot create the discussion, Care shows "Failed to create thread". + +## Expected Outcome + +- Care shows "Thread created successfully". +- Care opens the new discussion. You can post the first message. +- The new discussion shows only in the list of the context that you started it in. + +Note: Care shows no way to delete a discussion after you create it. + +## Related + +Concepts: + +- [Clinical Notes](../../../concepts/clinical/notes.mdx) + +Flows: + +- [Post a message to a discussion](./post-a-message.mdx) +- [Find discussions for a patient or an encounter](./find-discussions.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/questionnaire-response/_category_.json b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/_category_.json new file mode 100644 index 00000000..3ed9cea7 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Questionnaire Response", + "position": 10, + "key": "clinical-questionnaire-response-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/questionnaire-response/mark-a-response-as-entered-in-error.mdx b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/mark-a-response-as-entered-in-error.mdx new file mode 100644 index 00000000..4c59f4f5 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/mark-a-response-as-entered-in-error.mdx @@ -0,0 +1,71 @@ +--- +sidebar_position: 3 +--- + +# Mark a response as entered in error + +## Overview + +This flow describes how to mark a [questionnaire response](../../../concepts/clinical/questionnaire-response.mdx) as entered in error. Care then shows the response as invalid. + +## Pre-requisites + +- A user filed at least one response for the patient. +- You can read the responses of the patient, as described in [View questionnaire responses](./view-questionnaire-responses.mdx). +- A user filed the response through a form. Care does not offer this action for a response that a structured clinical record creates. An allergy record and a diagnosis record are structured clinical records. +- The response is not marked as entered in error. +- You mark the response inside the time limit that your deployment sets. After that time, only a system administrator can mark the response. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can submit questionnaire about patients | Lets you mark a patient-level response as entered in error. | +| Can submit questionnaire about patient encounters | Lets you mark a response of an encounter as entered in error. | + +Note: You need the same access that lets you submit the response. The access must match the patient or the encounter of the response. + +## Steps + +### 1. Open the list of responses + +Open the list of responses of the patient. [View questionnaire responses](./view-questionnaire-responses.mdx) describes this step. + +### 2. Open the actions menu of the response + +Find the response that you want to mark. Click **More Actions** on that response. + +Note: Care hides this menu for a response that is already marked as entered in error. + +### 3. Select Mark as entered in error + +Select **Mark as entered in error**. Care opens a confirmation dialog. + +Note: Care does not show this option for a response that a structured clinical record creates. + +### 4. Confirm the action + +Read the warning in the dialog. The dialog states that you cannot undo the action. It also states that Care marks the response as entered in error, and shows it as invalid. + +Click **Confirm**. Care updates the status of the response. + +Note: The time limit for this action depends on your deployment's configuration. After that time, only a system administrator can mark the response as entered in error. + +## Expected Outcome + +- Care marks the response as entered in error. +- Care shows the Entered in Error badge on the response, and closes the response in the list. +- You cannot change the response. +- You cannot remove the mark from the response. + +## Related + +Concepts: + +- [Questionnaire Response](../../../concepts/clinical/questionnaire-response.mdx) + +Flows: + +- [View questionnaire responses](./view-questionnaire-responses.mdx) +- [Print a questionnaire response](./print-a-questionnaire-response.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/questionnaire-response/print-a-questionnaire-response.mdx b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/print-a-questionnaire-response.mdx new file mode 100644 index 00000000..cf753b85 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/print-a-questionnaire-response.mdx @@ -0,0 +1,64 @@ +--- +sidebar_position: 2 +--- + +# Print a questionnaire response + +## Overview + +This flow describes how to print a [questionnaire response](../../../concepts/clinical/questionnaire-response.mdx). You can print one response, or all the responses to the same form. + +## Pre-requisites + +- A user filed at least one response for the patient. +- You can read the responses of the patient, as described in [View questionnaire responses](./view-questionnaire-responses.mdx). +- You have the permissions listed below. + +## Permissions + +You need the same read access that lets you read the list of responses. [View questionnaire responses](./view-questionnaire-responses.mdx) lists these permissions. + +## Steps + +### 1. Open the list of responses + +Open the list of responses of the patient. [View questionnaire responses](./view-questionnaire-responses.mdx) describes this step. + +### 2. Open the actions menu of the response + +Find the response that you want to print. Click **More Actions** on that response. + +Note: Care hides this menu for a response that is marked as entered in error. + +### 3. Choose what to print + +Select one of these options. + +| Option | What it prints | +| --- | --- | +| Print this response | The one response that you selected. | +| Print all responses | Every response to the same form. Care names the form in this option. | + +Note: Care shows the second option only for a response that comes from a form. A response that a structured clinical record creates does not have this option. + +Note: If you open the menu from an encounter, Care prints the responses of that encounter. If you open the menu from the patient, Care prints the responses of the patient. + +### 4. Print the page + +Care opens the print preview page **Questionnaire Response Logs**. Read the preview. Click **Print** to send the page to the printer. Click **Back** to return to the list. + +## Expected Outcome + +- Care opens a print preview of the response, or of all the responses to the form. +- The printer prints the page. + +## Related + +Concepts: + +- [Questionnaire Response](../../../concepts/clinical/questionnaire-response.mdx) + +Flows: + +- [View questionnaire responses](./view-questionnaire-responses.mdx) +- [Mark a response as entered in error](./mark-a-response-as-entered-in-error.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/questionnaire-response/view-questionnaire-responses.mdx b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/view-questionnaire-responses.mdx new file mode 100644 index 00000000..894ebfa4 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/questionnaire-response/view-questionnaire-responses.mdx @@ -0,0 +1,81 @@ +--- +sidebar_position: 1 +--- + +# View questionnaire responses + +## Overview + +This flow describes how to read the [questionnaire responses](../../../concepts/clinical/questionnaire-response.mdx) that users filed for a patient. Care shows the responses in three places. + +## Pre-requisites + +- The patient is registered in Care. +- A user filed at least one response for the patient. +- If you open the responses from an encounter, that encounter belongs to the patient. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can view questionnaire responses on patient | Lets you open the **Updates** tab of the patient and read the responses. | +| Can Read encounter related clinical data | Lets you read the responses of an encounter. | +| Can view clinical data about patients | Lets you read the responses of an encounter of the patient. | + +Note: For the responses of an encounter, one of the last two permissions is enough. + +## Steps + +### 1. Choose where to open the responses + +Choose one of these three entry points: + +- Open the **Updates** tab of the patient. This tab lists the responses to patient-level forms. +- Open the **Responses** tab of the encounter. This tab lists the responses to the forms of that encounter. Inside an encounter, press `g` then `r` to open this tab. +- Open the **Clinical History** page of the patient, then go to the **Responses** section. This section lists the responses across all encounters of the patient. Inside an encounter, press `h` to open the clinical history. + +Note: The **Updates** tab shows an **Add Patient Updates** button if you have permission to submit patient-level forms. + +### 2. Read the list of responses + +On the **Responses** tab and on the **Clinical History** page, Care shows two panels on a large screen. The left panel lists short cards. The right panel shows the full response that you select. On a small screen, the left panel closes. Click **View Responses** to open the list. + +Each response shows this information: + +| Components | What it captures | +| --- | --- | +| Title | The name of the form. A response that a structured clinical record creates shows the type of that record, for example Allergy Intolerance. | +| Date and time | When the user filed the response. | +| Filed by | The user who filed the response. | +| Entered in Error | A badge that marks the response as invalid. | + +Note: Care closes a response with the Entered in Error badge. Click the response to open it. + +### 3. Filter the list by form + +On the **Responses** tab and on the **Clinical History** page, click **Select Forms** in the left panel. Select the form that you want to read. Care then lists only the responses to that form. + +To clear the filter, click the clear icon in the **Select Forms** button. + +Note: You can also click the title of a response. Care then filters the list to that form. + +### 4. Open a response + +Click a card in the left panel. Care shows the full response in the right panel. The response groups the answers by question. Click **See Note** on an answer to read the note that the user attached. + +## Expected Outcome + +- Care lists the responses of the patient or of the encounter. +- Care shows the answers and the notes of the response that you select. + +## Related + +Concepts: + +- [Questionnaire Response](../../../concepts/clinical/questionnaire-response.mdx) + +Flows: + +- [Print a questionnaire response](./print-a-questionnaire-response.mdx) +- [Mark a response as entered in error](./mark-a-response-as-entered-in-error.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/service-request/_category_.json b/versioned_docs/version-3.1/flows/clinical/service-request/_category_.json new file mode 100644 index 00000000..5dade9f6 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/service-request/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Service Request", + "position": 5, + "key": "clinical-service-request-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/service-request/cancel-a-service-request.mdx b/versioned_docs/version-3.1/flows/clinical/service-request/cancel-a-service-request.mdx new file mode 100644 index 00000000..b95cf676 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/service-request/cancel-a-service-request.mdx @@ -0,0 +1,63 @@ +--- +sidebar_position: 4 +--- + +# Cancel a service request + +## Overview + +This flow describes how to cancel a [service request](../../../concepts/clinical/service-request.mdx) that the care team no longer needs. + +## Pre-requisites + +- You raised a service request for the patient, or another user raised it, and you can open its detail page. +- The service request is not complete and not already cancelled. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Write Service Request on Facility | Cancel a service request at the facility. Facility Admin, Admin, Doctor, and Nurse hold this permission. | + +## Steps + +### 1. Open the service request + +Open the detail page of the service request that you want to cancel. + +### 2. Open the actions menu + +Select the actions menu at the top of the detail page. Care shows the two cancel actions. + +### 3. Select the end state + +Select one of the two actions. + +| Action | What it means | +| --- | --- | +| Mark as revoked | The care team called off the request. Care sets the status to Revoked. | +| Mark as entered in error | The care team created the request by mistake. Care sets the status to Entered in Error. | + +Note: Care cancels the service request at once. Care does not ask you to confirm. + +Note: If the service request is complete or already cancelled, Care blocks the cancellation. + +## Expected Outcome + +- Care sets the service request to Revoked or to Entered in Error. +- The service request becomes read-only. You can no longer change it. +- If the service request has a linked billing charge, Care sets that charge to Aborted. Care also removes the charge from the draft invoice. +- If the linked invoice is not a draft, Care blocks the cancellation. + +## Related + +Concepts: + +- [Service Request](../../../concepts/clinical/service-request.mdx) + +Flows: + +- [Create a service request](./create-a-service-request.mdx) +- [View service requests](./view-service-requests.mdx) +- [Complete a service request](./complete-a-service-request.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/service-request/complete-a-service-request.mdx b/versioned_docs/version-3.1/flows/clinical/service-request/complete-a-service-request.mdx new file mode 100644 index 00000000..f4107e9e --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/service-request/complete-a-service-request.mdx @@ -0,0 +1,64 @@ +--- +sidebar_position: 3 +--- + +# Complete a service request + +## Overview + +This flow describes how to mark a [service request](../../../concepts/clinical/service-request.mdx) as complete in Care. You complete the service request after the requested work is finished. + +## Pre-requisites + +- You raised a service request for the patient, or another user raised it, and you can open its detail page. +- The requested work is finished. For a laboratory request, the staff collected and processed the specimens. The staff also entered the results. For a surgical procedure or a counselling request, the staff finished the work. +- The service request is not complete and not cancelled. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Write Service Request on Facility | Lets you complete a service request. Facility Admin, Admin, Doctor, and Nurse roles have this permission. | + +## Steps + +### 1. Open the service request + +Open the detail page of the service request that you want to complete. + +### 2. Confirm that the work is finished + +Check that the staff finished the requested work. + +Note: For a laboratory request, check that the staff collected the specimens, processed them, and entered the results. + +Note: For a surgical procedure or a counselling request, complete the service request directly. + +### 3. Mark the service request as complete + +1. Select **Mark as Complete** in the **Complete Service Request** bar at the foot of the page. +2. Enter a completion note in the **Add Completion Note** dialog. This note records the key findings or remarks for the request. +3. Select **Save and Complete**. Care sets the status of the service request to Completed. + +Note: Press M to start the **Mark as Complete** action. + +Note: You cannot undo this action. Care blocks the action when the service request is already complete. Care also blocks the action when somebody cancelled the service request. + +## Expected Outcome + +- The status of the service request changes to Completed. +- The service request becomes read-only. You can no longer change it. +- The specimens and the diagnostic reports of the service request do not change. The complete action changes only the status of the service request. + +## Related + +Concepts: + +- [Service Request](../../../concepts/clinical/service-request.mdx) + +Flows: + +- [Create a service request](./create-a-service-request.mdx) +- [View service requests](./view-service-requests.mdx) +- [Cancel a service request](./cancel-a-service-request.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/service-request/create-a-service-request.mdx b/versioned_docs/version-3.1/flows/clinical/service-request/create-a-service-request.mdx new file mode 100644 index 00000000..0435f3a2 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/service-request/create-a-service-request.mdx @@ -0,0 +1,94 @@ +--- +sidebar_position: 1 +--- + +# Create a service request + +## Overview + +This flow describes how to raise a new [service request](../../../concepts/clinical/service-request.mdx) for a patient from an encounter in Care. A service request asks another team to do a test, a procedure, or another service for the patient. + +## Pre-requisites + +- The patient is registered in Care. +- The patient has an encounter at the facility, and you record the service request under that encounter. +- The encounter is still open. Care hides the create option for a completed or an inactive encounter. +- You are a member of the facility. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Write Service Request on Facility | Create and change service requests for patients at the facility. Facility Admin, Admin, Doctor, and Nurse roles hold this permission. | + +## Steps + +### 1. Open the patient's encounter + +1. Open the patient in the facility. +2. Open the encounter for which you raise the service request. + +### 2. Open the Service Requests tab + +Select the **Service Requests** tab in the encounter. + +Care shows the service requests that already exist for the encounter. + +Note: Press G and then S to open the **Service Requests** tab. + +### 3. Start a new service request + +Select **Create Service Request**. + +Care opens the service request form for the encounter. + +Note: Care shows the **Create Service Request** option only when the encounter is open. + +### 4. Select the service + +Select a service in the **Select Activity Definition** list. Care adds a card for that service to the form. + +Care copies the title, the category, and the code from the service that you select. Care also copies the body site, the locations, and the healthcare service. Care sets the status to Active, the intent to Order, and the priority to Routine. Care sets you as the requester. + +To request more than one service, select another service in the same list. + +### 5. Fill in the service request details + +Open the card of the service and complete the fields. + +| Components | What it captures | +| --- | --- | +| Priority | How urgent the request is: Routine, Urgent, ASAP, or STAT. This field is mandatory. | +| Body Site | The part of the body for the service. | +| Patient Instruction | The instructions for the patient, such as how to prepare for a test. | +| Requester | The facility member who asks for the service. | +| Note | More information for the team that does the service. | + +Care takes the patient and the encounter from the page that you start on. You do not select the patient. + +Note: When the form holds more than one service, select **Apply to All** to set the same requester for every service. + +Note: Which fields are mandatory depends on your deployment's configuration. + +### 6. Submit the service request + +Select **Submit**. + +## Expected Outcome + +- Care creates the service request for the patient under the current encounter. +- The new request shows in the Service Requests list of the encounter. + +## Related + +Concepts: + +- [Service Request](../../../concepts/clinical/service-request.mdx) +- [Encounter](../../../concepts/clinical/encounter.mdx) + +Flows: + +- [View service requests](./view-service-requests.mdx) +- [Complete a service request](./complete-a-service-request.mdx) +- [Cancel a service request](./cancel-a-service-request.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/service-request/view-service-requests.mdx b/versioned_docs/version-3.1/flows/clinical/service-request/view-service-requests.mdx new file mode 100644 index 00000000..b48f2fba --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/service-request/view-service-requests.mdx @@ -0,0 +1,93 @@ +--- +sidebar_position: 2 +--- + +# View service requests + +## Overview + +This flow describes how to find and open a [service request](../../../concepts/clinical/service-request.mdx) in Care. You can view the requests for one encounter, or the requests for a facility location. + +## Pre-requisites + +- The patient is registered in Care, and the patient has an encounter at the facility. +- You or another user created at least one service request for the patient. +- You are a member of the facility. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read Service Request | Lets you open the service request list and the detail page. Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, Volunteer, and Pharmacist have this permission. | + +## Steps + +### 1. Open the service request list + +Open the encounter of the patient. Select the **Service Requests** tab. Care shows a table of the service requests for that encounter. + +To see the requests for a facility location, open the location and select its requests list. This list shows the same table for all patients at that location. + +The table has these columns. + +| Column | What it shows | +| --- | --- | +| Patient Name | The name of the patient. Care shows this column only in the list of a facility location. | +| Service Type | The type of service that the request asks for. | +| Status/Priority | The current status and the priority of the request. | +| Tags | The tags on the request. | +| Location | The location that is responsible for the request. | +| Actions | The **See Details** button. | + +### 2. Find a service request + +Use the **Status** filter to show the requests with one status. Use the **Priority** filter to show the requests with one priority. Enter a word in the search box to find a request by title. + +### 3. Open the detail page + +Select **See Details** on the row of the request. Care opens the detail page of the service request. + +The detail page shows this information. + +| Information | What it shows | +| --- | --- | +| Title | The title of the request. | +| Intent | The intent of the request. | +| Priority | The priority of the request. | +| Status | The current status of the request. | +| Do Not Perform | The **Do Not Perform** flag. Care shows this only when a user sets the flag. | +| Observation and test requirements | The observations and tests that the request asks for. | +| Specimen requirements | The specimens that the request needs. | +| Body Site | The body site for the request. | +| Healthcare Service | The linked healthcare service. Care shows this only when the request has a linked service. | +| Requester | The facility member who asked for the service. | +| Location | The current location of the patient. | +| Patient Instruction | The instruction for the patient. | +| Note | The note on the request. | + +### 4. Review the linked records + +Look at the **Specimens** section for the linked [specimens](../../../concepts/clinical/specimen.mdx). Care shows this section only when the activity of the request has specimen requirements. + +Look at the linked [diagnostic reports](../../../concepts/clinical/diagnostic-report.mdx) on the same page. + +## Expected Outcome + +- You see the service requests for the encounter or the location in one table. +- You see the full details of one service request on its detail page. +- You see the specimens and the diagnostic reports that link to the service request. + +## Related + +Concepts: + +- [Service Request](../../../concepts/clinical/service-request.mdx) +- [Specimen](../../../concepts/clinical/specimen.mdx) +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [Create a service request](./create-a-service-request.mdx) +- [Complete a service request](./complete-a-service-request.mdx) +- [Cancel a service request](./cancel-a-service-request.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/specimen/_category_.json b/versioned_docs/version-3.1/flows/clinical/specimen/_category_.json new file mode 100644 index 00000000..53bde586 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/specimen/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Specimen", + "position": 6, + "key": "clinical-specimen-flows" +} diff --git a/versioned_docs/version-3.1/flows/clinical/specimen/collect-a-specimen.mdx b/versioned_docs/version-3.1/flows/clinical/specimen/collect-a-specimen.mdx new file mode 100644 index 00000000..9e26a8d6 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/specimen/collect-a-specimen.mdx @@ -0,0 +1,90 @@ +--- +sidebar_position: 1 +--- + +# Collect a specimen + +## Overview + +This flow describes how to collect a [specimen](../../../concepts/clinical/specimen.mdx) for a service request in Care. You record the collection details and identify the specimen with a QR code or an accession identifier. + +## Pre-requisites + +- A user created a service request for the patient, and you open that service request. +- The requested test or procedure needs one or more specimens. +- The service request is in Draft or Active status. You can edit specimen fields only in these two statuses. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Create Specimen on Facility | Lets you collect a specimen for a service request at the facility. Facility Admin, Admin, Doctor, and Nurse have this permission. | + +## Steps + +### 1. Open the service request + +Open the detail page of the service request that needs the specimen. + +The page shows a **Specimens** section. This section lists one card for each required specimen type. Each card shows the collection instructions for that specimen type. + +### 2. Start the collection + +Select **Collect Specimen** on the card of the specimen type that you collect. + +Care creates a draft specimen and opens the collection form. + +### 3. Record the collection details + +Enter the collection details in the form. + +| Component | What it captures | +| --- | --- | +| Collection Date & Time | The date and time of the collection. This field is optional. | +| Quantity | The collected amount and its unit. If you enter one of the two, enter both. | +| Body Site | The part of the body that you collect the specimen from. This field is optional. | +| Fasting Status | The fasting state of the patient, and the fasting duration. This field is optional. | +| Notes | More information about the collection. This field is optional. | + +The form also shows the container requirements for the specimen type, if the type defines them. These requirements are read-only. + +Note: Care records you as the collector of the specimen. + +### 4. Identify the specimen + +Select how you identify the specimen with the **Generate QR Code** and **Scan Existing** toggle. + +- To create a new identifier, select **Generate QR Code**. +- To use an identifier that the container already has, select **Scan Existing**. Scan the accession identifier, or type it. + +### 5. Submit the form + +Select the submit button on the collection form. + +Care changes the status of the specimen from Draft to Available. + +### 6. Print the labels + +To print the QR code labels, go back to the service request page. Select **Print All QR Codes**. Care prints a label for each selected specimen. + +## Expected Outcome + +- Care records the specimen with your collection details. +- The status of the specimen changes from Draft to Available. +- The specimen has a QR code or an accession identifier. +- You can print a QR code label for the specimen from the service request page. + +## Related + +Concepts: + +- [Specimen](../../../concepts/clinical/specimen.mdx) +- [Service Request](../../../concepts/clinical/service-request.mdx) + +Flows: + +- [Process a specimen](./process-a-specimen.mdx) +- [Discard a specimen](./discard-a-specimen.mdx) +- [View specimen history](./view-specimen-history.mdx) +- [View service requests](../../../flows/clinical/service-request/view-service-requests.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/specimen/discard-a-specimen.mdx b/versioned_docs/version-3.1/flows/clinical/specimen/discard-a-specimen.mdx new file mode 100644 index 00000000..06f795c2 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/specimen/discard-a-specimen.mdx @@ -0,0 +1,63 @@ +--- +sidebar_position: 3 +--- + +# Discard a specimen + +## Overview + +This flow describes how to discard a [specimen](../../../concepts/clinical/specimen.mdx) in Care and record the reason for the discard. + +## Pre-requisites + +- You collected the specimen, and the specimen card shows on the service request page. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Create Specimen on Facility | Lets you discard a specimen at the facility. Facility Admin, Admin, Doctor, and Nurse have this permission. | + +## Steps + +### 1. Open the specimen card menu + +Go to the service request page. Find the card of the specimen that you discard. Open the menu on the specimen card. + +### 2. Select Discard + +Select **Discard** in the menu. Care opens a confirmation dialog. The dialog asks for the reason for the discard. + +### 3. Select the reason and confirm + +Select one of these reasons: + +| Reason | What it records | +| --- | --- | +| Unavailable | The specimen is not available. | +| Unsatisfactory | The specimen does not meet the quality requirements. | +| Entered in Error | A user created the specimen by mistake. | + +Confirm the dialog. Care sets the status of the specimen to the reason that you select. + +Note: The three reason labels in this dialog show in English only. The current build does not translate them to other languages. + +Note: A discard is final. A discarded specimen does not return to the Available status. + +## Expected Outcome + +- Care shows the specimen with the status that matches the reason that you select. +- The specimen stays discarded, and you cannot return it to the Available status. + +## Related + +Concepts: + +- [Specimen](../../../concepts/clinical/specimen.mdx) + +Flows: + +- [Collect a specimen](./collect-a-specimen.mdx) +- [Process a specimen](./process-a-specimen.mdx) +- [View specimen history](./view-specimen-history.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/specimen/process-a-specimen.mdx b/versioned_docs/version-3.1/flows/clinical/specimen/process-a-specimen.mdx new file mode 100644 index 00000000..9f22b638 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/specimen/process-a-specimen.mdx @@ -0,0 +1,68 @@ +--- +sidebar_position: 2 +--- + +# Process a specimen + +## Overview + +This flow describes how to record a processing step for a collected [specimen](../../../concepts/clinical/specimen.mdx) in Care. A processing step is work done on the specimen before testing, such as centrifuging or staining. + +## Pre-requisites + +- You collected the specimen, and the specimen card shows on the service request page. +- No user created a diagnostic report for the service request. Care hides the processing section after a diagnostic report exists for the service request. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Create Specimen on Facility | Lets you record processing steps on a specimen at the facility. Facility Admin, Admin, Doctor, and Nurse have this permission. | + +## Steps + +### 1. Open the service request page + +Open the service request for the specimen. The page shows a card for each specimen. + +### 2. Find the processing section + +Go to the card of the collected specimen. The card shows the processing section. + +Note: Care shows the processing section only after you collect the specimen. + +### 3. Select the processing method + +Select the processing method from the coded list. The method names the work done on the specimen. + +### 4. Add the description + +Care opens a dialog. Enter a description of the processing step. Save the processing step. + +| Components | What it captures | +| --- | --- | +| Method | The processing method from the coded list. | +| Description | Your description of the processing step. | + +### 5. Add more processing steps + +Repeat steps 3 and 4 for each further processing step. Care keeps all steps on the specimen. + +## Expected Outcome + +- The specimen shows the processing step with the method, the description, the performer, and the time. +- The specimen keeps every processing step that you add. + +## Related + +Concepts: + +- [Specimen](../../../concepts/clinical/specimen.mdx) +- [Diagnostic Report](../../../concepts/clinical/diagnostic-report.mdx) + +Flows: + +- [Collect a specimen](./collect-a-specimen.mdx) +- [Discard a specimen](./discard-a-specimen.mdx) +- [View specimen history](./view-specimen-history.mdx) diff --git a/versioned_docs/version-3.1/flows/clinical/specimen/view-specimen-history.mdx b/versioned_docs/version-3.1/flows/clinical/specimen/view-specimen-history.mdx new file mode 100644 index 00000000..ecdac2c3 --- /dev/null +++ b/versioned_docs/version-3.1/flows/clinical/specimen/view-specimen-history.mdx @@ -0,0 +1,65 @@ +--- +sidebar_position: 4 +--- + +# View specimen history + +## Overview + +This flow describes how to review earlier [specimens](../../../concepts/clinical/specimen.mdx) for a service request in Care. The history shows specimens marked as Entered in Error or Unsatisfactory. + +## Pre-requisites + +- You are a member of the facility that holds the service request. +- A user collected at least one specimen for the service request. +- You have the permissions listed below. + +## Permissions + +| Permission | Access | +| --- | --- | +| Can Read Specimen | View specimens and the specimen history for a service request. Facility Admin, Administrator, Admin, Staff, Doctor, Nurse, and Pharmacist hold this permission. | + +## Steps + +### 1. Open the service request page + +Open the service request that holds the specimen. + +### 2. Open the specimen history + +Open the menu on the specimen. Select **View Specimen History**. Care opens the history panel for that service request. + +### 3. Review the specimens + +The panel lists each Entered in Error or Unsatisfactory specimen as a card. Each card shows the fields below. + +| Field | What it shows | +| --- | --- | +| Specimen Type | The type of material that the user collected. | +| Collected At | The date and time of the collection. | +| Quantity | The amount of material that the user collected. | +| Collection Method | The method that the user used to collect the specimen. | +| Notes | The remarks that the user recorded for the specimen. | + +### 4. Look up a specimen by accession identifier + +Scan the accession identifier on the specimen container. You can also type the accession identifier. Care opens the service request that owns the specimen. + +## Expected Outcome + +- Care shows the Entered in Error and Unsatisfactory specimens for the service request as cards. +- Care opens the owning service request when you look up an accession identifier. + +## Related + +Concepts: + +- [Specimen](../../../concepts/clinical/specimen.mdx) +- [Service Request](../../../concepts/clinical/service-request.mdx) + +Flows: + +- [Collect a specimen](./collect-a-specimen.mdx) +- [Process a specimen](./process-a-specimen.mdx) +- [Discard a specimen](./discard-a-specimen.mdx) diff --git a/versioned_sidebars/version-3.1-sidebars.json b/versioned_sidebars/version-3.1-sidebars.json index 43daff53..1e44cf57 100644 --- a/versioned_sidebars/version-3.1-sidebars.json +++ b/versioned_sidebars/version-3.1-sidebars.json @@ -77,6 +77,92 @@ "flows/clinical/condition/condition-entered-in-error", "flows/clinical/condition/view-clinical-history" ] + }, + { + "type": "category", + "label": "Service Request", + "key": "clinical-service-request-flows", + "items": [ + "flows/clinical/service-request/create-a-service-request", + "flows/clinical/service-request/view-service-requests", + "flows/clinical/service-request/complete-a-service-request", + "flows/clinical/service-request/cancel-a-service-request" + ] + }, + { + "type": "category", + "label": "Specimen", + "key": "clinical-specimen-flows", + "items": [ + "flows/clinical/specimen/collect-a-specimen", + "flows/clinical/specimen/process-a-specimen", + "flows/clinical/specimen/discard-a-specimen", + "flows/clinical/specimen/view-specimen-history" + ] + }, + { + "type": "category", + "label": "Diagnostic Report", + "key": "clinical-diagnostic-report-flows", + "items": [ + "flows/clinical/diagnostic-report/enter-diagnostic-report-results", + "flows/clinical/diagnostic-report/view-a-diagnostic-report", + "flows/clinical/diagnostic-report/update-a-diagnostic-report", + "flows/clinical/diagnostic-report/print-a-diagnostic-report" + ] + }, + { + "type": "category", + "label": "Consent", + "key": "clinical-consent-flows", + "items": [ + "flows/clinical/consent/record-a-consent", + "flows/clinical/consent/view-consents", + "flows/clinical/consent/update-a-consent", + "flows/clinical/consent/verify-a-consent" + ] + }, + { + "type": "category", + "label": "Files", + "key": "clinical-files-flows", + "items": [ + "flows/clinical/files/upload-a-file", + "flows/clinical/files/view-or-preview-a-file", + "flows/clinical/files/rename-a-file", + "flows/clinical/files/archive-a-file", + "flows/clinical/files/download-a-file" + ] + }, + { + "type": "category", + "label": "Questionnaire Response", + "key": "clinical-questionnaire-response-flows", + "items": [ + "flows/clinical/questionnaire-response/view-questionnaire-responses", + "flows/clinical/questionnaire-response/print-a-questionnaire-response", + "flows/clinical/questionnaire-response/mark-a-response-as-entered-in-error" + ] + }, + { + "type": "category", + "label": "Care Team", + "key": "clinical-care-team-flows", + "items": [ + "flows/clinical/care-team/add-care-team-members", + "flows/clinical/care-team/view-the-care-team", + "flows/clinical/care-team/modify-the-care-team" + ] + }, + { + "type": "category", + "label": "Notes", + "key": "clinical-notes-flows", + "items": [ + "flows/clinical/notes/start-a-discussion", + "flows/clinical/notes/post-a-message", + "flows/clinical/notes/find-discussions" + ] } ] },