PurchaseRequisition (zapotrzebowanie)
PurchaseRequisition (zapotrzebowanie / rekwizycja) to zasób WMS służący do przyjęcia i przechowywania zapotrzebowania utworzonego w systemie zewnętrznym i przekazanego do obsługi przez system magazynowy.
Zapotrzebowanie nie jest dokumentem księgowym – nie zawiera cen. Zawiera nagłówek i listę pozycji (position[]) z produktem (asortyment) i ilością.
1. Zakres i zastosowanie
- Wejście do WMS: system zewnętrzny przekazuje zapotrzebowanie, a system docelowy tworzy u siebie dokument
PurchaseRequisitionz wiązaniem do identyfikatorów źródłowych. - Identyfikowalność: powiązanie z systemem źródłowym jest utrzymywane przez
identifier[]oraz (dla danych pomocniczych)attribute[]. - Zakres zasobu: przyjęcie i utrzymanie zapotrzebowania przekazanego z systemu zewnętrznego; zamówienia do dostawców, GR/FV, przesunięcia i rozchody na pacjenta leżą poza tym zasobem i są modelowane innymi typami (np.
PurchaseOrder,InventoryDocument,Invoice).
2. Zawartość (struktura)
Oprócz wspólnych pól zasobów kanonicznych (id, meta, identifier, status, type, category, attribute), zasób zawiera:
| Nazwa | Kard. | Typ | Opis |
|---|---|---|---|
| symbol | 0..* | CodeableConcept | Symbol dokumentu zapotrzebowania |
| warehouse | 0..1 | Reference(Location) | Magazyn kontekstowy (Location z type=warehouse) |
| participant | 0..* | Reference | Uczestnicy (np. oddział zamawiający, apteka realizująca) |
| relatedDocument | 0..* | Reference | Powiązane dokumenty (np. dokument EOD, zamówienie zakupu PurchaseOrder, dokument ruchu InventoryDocument) |
| issueDate | 0..1 | dateTime | Data i czas utworzenia |
| expectedDate | 0..1 | dateTime | Oczekiwana data i czas realizacji |
| description | 0..1 | string | Opis |
| note | 0..1 | string | Uwagi |
| transferDate | 0..1 | dateTime | Data przekazania |
| realizationDate | 0..1 | dateTime | Data zrealizowania zapotrzebowania |
| position | 1..* | PurchaseRequisitionPosition | Pozycje: produkt + ilość żądana |
2a. PurchaseRequisitionPosition (pozycja)
Pozycje są zgodne kształtem z podejściem WMS jak w InventoryDocumentPosition:
| Nazwa | Kard. | Typ | Opis |
|---|---|---|---|
| positionNo | 1..1 | integer | Numer pozycji (od 1) |
| product | 1..1 | Reference | Referencja do ProductDefinition (asortyment) |
| quantity | 1..1 | Quantity | Ilość żądana (value > 0) |
| priority | 0..1 | CodeableConcept | Priorytet pozycji (np. normal, cito, stat) |
| type | 0..1 | CodeableConcept | Typ pozycji (np. gotowy / składnik robionego / nagłówek robionego) |
| factor | 0..1 | number | Mnożnik/przelicznik dla ilości |
| attribute | 0..* | Attribute | Dodatkowe dane przejściowe i rozszerzenia (gdy nie pasują do pól jawnych) |
| status | 0..1 | CodeableConcept | Opcjonalny status pozycji (np. częściowo zrealizowana) |
| creationTime | 0..1 | dateTime | Data utworzenia pozycji |
| fulfilledQuantity | 0..1 | integer | Ilość zrealizowana podana lekospisowo (opakowania), może być częściowo zrealizowane |
| description | 0..1 | string | Opis pozycji |
2b. Kontekst medyczny i operacyjny (profil / rozszerzenia)
Rdzeń zasobu nie przewiduje osobnych pól dla pacjenta, lekarza ani numeru zlecenia (np. zleceń specjalistycznych w obiegu szpitalnym), które mogą towarzyszyć pozycji zapotrzebowania w systemie źródłowym.
Typowa integracja z API.ERP (magazyn / zamówienia wewnętrzne): identyfikatory i numery ze źródła (pacjent, lekarz, zlecenie) zapisuje się w attribute[] na nagłówku lub pozycji — z ustalonym zestawem kodów (Attribute.code) we własnym profilu WMS lub profilu uzgodnionym z operatorem API. W ten sposób dane są przenoszalne i walidowalne bez rozszerzania kanonicznego schematu pola po polu.
Instalacje łączące szpitalny obieg kliniczny z API.ERP: KAMSOFT oferuje osobno API.MED — interfejsy pod dane medyczne (np. pacjent, wizyta, zlecenie w ujęciu klinicznym), zwykle zbliżone modelem do HL7 FHIR. API.ERP (ten przewodnik) opisuje wyłącznie warstwę gospodarczą (m.in. zapotrzebowanie magazynowe). Gdy umowa o integrację przewiduje powiązanie zapotrzebowania z rekordem klinicznym, profil instalacji może dopuścić Reference do zasobu opisanego w dokumentacji API.MED (ten sam identyfikator co w systemie klinicznym). Integrator nie zakłada obecności API.MED: stosuje się wyłącznie to, co wynika z profilu i kontraktu dla danej placówki.
3. Mapowanie z modelem źródłowym (niekanoniczny przykład)
Typowe mapowanie:
source_document_id→PurchaseRequisition.identifier[](np. systemsource-document-id)symbol→symbol.coding[0].codestatus→status.coding[0].code(przeniesienie 1:1 kodu z systemu źródłowego)expected_date→expectedDate(dateTime)assortment_id→position[].product.reference(np.ProductDefinition/{id})amount+unit_*→position[].quantity+position[].attribute[]
4. Artefakty
- Schemat:
schemas/canonical-wms/PurchaseRequisition.schema.json - Schemat pozycji:
schemas/canonical-wms/PurchaseRequisitionPosition.schema.json