Skip to main content

Clinical records and hospital orders

GP Records's Journal shows dated contacts with their recorded narrative and authors. Search includes note text. Expand Record details and activity to inspect the history or open an action.

Hospital documentation​

Open a patient in Hospital EPR and choose Documentation or New note. Select a free-text, history-and-physical or progress-note template. The section navigator moves between parts of the note.

Save draft stores an editable note. Review & sign previews the note before Confirm & sign records the signature. Signed text is preserved. Use Add addendum to append further information with its own attribution. Drafts and signed notes remain in the documentation list after reload.

Prescriptions and blood tests​

Prescription opens the medication catalogue and order details. Enter the medicine, dose, unit, route, frequency, duration, quantity and indication. Review the details before sending the draft to pharmacy. Pharmacy review and approval are still required before dispensing.

Request test opens the laboratory catalogue. Choose a supported panel, specimen, priority, collection round and clinical details. Review and sign the request. Results become available after 120 simulation minutes for collection now, or 240 minutes for the next round.

The Orders view retains the submitted details. Results shows measurements against sample dates. Use the panel navigator to filter the grid, or select measurements and choose Graph selected to inspect trends. Values and reference intervals are synthetic.

Agent requests​

These workflows use POST /api/sites/hospital/actions with the team's API key. Patient records are read through GET /api/sites/hospital/view?patient=SIM-000006.

The Secondary care group in the API explorer also exposes raw records:

  • GET /api/sites/hospital/consultations?patient=SIM-000006 returns hospital-owned consultation records, including saved note sections, full text, signatures, and addenda where recorded.
  • GET /api/sites/hospital/genomes?patient=SIM-000006 returns the resident's raw synthetic genomic records.

Both require hospital scope and return items, total, offset, limit, and the simulation time now. Each item retains its resource ID, version, original data, and provenance. Use limit from 1 to 500 and increase offset to page through results. The default limit is 100. Omitting patient reads across the team's world. An unknown patient returns an empty list.

The consultation endpoint includes hospital-owned hospital-note, clinical-note, consultation, and encounter records. Their data shapes depend on the record kind. GP consultations and discharge-summary documents are separate records.

Synthetic genomic records​

Every synthetic patient receives a hospital-only CYP2C19 SNP panel for the clopidogrel integration scenario. The panel contains unphased genotype calls for rs4244285, rs4986893, and rs12248560. The SNP identifiers and reference alleles follow PharmVar's CYP2C19 catalogue. Patient genotypes are deterministic synthetic fixtures, unrelated to real patients or population frequencies.

data.variants contains each SNP's identifier, reference allele, alternate allele, and diploid genotype. The panel labels itself as synthetic and identifies its source. It is a targeted SNP fixture, not a whole-genome sequence, inferred haplotype, or prescribing recommendation.

Existing populations and team-specific patients receive missing panels through a transactional startup migration. Repeated startup preserves existing records. New patients receive a panel when generated. Genome records remain owned by and visible to hospital; generic actions cannot edit or share them with another service. Operator access remains available for simulation administration.

The OpenAPI document describes the response schemas. The genome endpoint returns genome-record resources. The older genomic-test workflow stub is not a raw SNP record.

Submit hospital actions​

  • Notes use type: "hospital_note" and hospitalNoteCommand. The command is {kind: "save", template, sections} for drafts, {kind: "sign"} for signing, or {kind: "addendum", text} for additions. Each section contains id, heading and text. Creation also requires patientId and title; edits require resourceId and expectedVersion.
  • Prescriptions use type: "draft_prescription", patientId, title and medicationOrder, containing drug, dose, unit, route, frequency, duration, quantity and indication.
  • Laboratory requests use type: "order_test", patientId, title and bloodTestOrder, containing panel, panelId, specimen, priority, collection and clinicalDetails. Supported panel IDs are fbc, ue, hba1c, lft, crp and lipids. Collection is now or next-round.

Supply an Idempotency-Key header or a clientRequestId UUID and reuse it for an identical retry. Stale edits and attempts to overwrite signed notes fail without changing the record.

Deceased synthetic patients​

Patient records include an optional death object with the date, authored cause, synthetic: true, and source authored-synthetic-mortality-v1. Its presence means the patient is deceased. GP and hospital records show the status, date, cause, and age at death. Existing consultation and medication history remains available.

The fixtures are SIM-000009 (road traffic collision), SIM-000011 (pneumonia), SIM-000012 (sepsis), SIM-000018 (cancer), and SIM-000019 (stroke). Names, dates of birth, and ages can differ between populations. Read the current patient record for those values. These causes are authored simulation data.

The startup migration adds the fixtures to existing shared populations and patient overlays without changing demographics or replacing existing death records. New generated populations receive the same fixture IDs. Deceased patients are excluded from future generated demand and new telephone calls. Patient APIs retain the death object; PDS FHIR Patient responses include deceasedDateTime. FHIR active continues to describe record availability.

Issue and approve primary care prescriptions​

Use a team key with gp scope. All records are synthetic.

  1. POST to /api/sites/gp/actions with type: "draft_prescription", patientId, title, and the medicationOrder fields listed above. The response contains the prescription id, version, and status: "draft".
  2. Retrieve prescriptions with GET /api/sites/gp/prescriptions?patient=SIM-000001&offset=0&limit=100. The response contains items, total, offset, and limit. Each item includes its medication details, status, version, and provenance. Omit patient to list all GP-visible prescriptions. The maximum limit is 500.
  3. POST to /api/sites/gp/actions with type: "review", resourceId, and the latest expectedVersion. The status becomes reviewed.
  4. POST to the same endpoint with type: "accept", resourceId, and the version returned by review. The status becomes approved.

GP can review and approve prescriptions originally issued through GP. Sharing a hospital prescription with GP permits retrieval but does not grant approval permission. Pharmacy retains ownership and handles stock linking, dispensing, and collection. A GP-only key can complete issuance and approval without pharmacy scope.

Approval before review and stale versions return 409. Missing versions on GP review or approval return 400. Unauthorized service changes return 403. Send an Idempotency-Key header when creating or changing a prescription to retry that exact request safely.