Profil CDA

Profil prywatny KAMSOFT dokumentu HL7 CDA do wymiany skierowań na badania profilaktyczne między pracodawcą a podmiotem służby medycyny pracy. Specyfikacja techniczna, wersja robocza 0.1.

Status: draft · Standard: HL7 CDA R2 · Wzorzec: HL7POL IK 1.3.2 · Profil: prywatny KAMSOFT · Wymiana: lokalna · nie przez P1 · Przykład XML: profil v0.3

01 · Kontekst biznesowy i zakres

Pracodawca, na podstawie art. 229 Kodeksu pracy, kieruje pracownika na badanie profilaktyczne (wstępne, okresowe lub kontrolne) do podmiotu służby medycyny pracy. Skierowanie ma formę dokumentu pisemnego, który pracownik zabiera ze sobą do PSMP lub który jest przekazywany elektronicznie.

Cel dokumentu

Zdefiniowanie elektronicznej formy skierowania na badanie medycyny pracy, wymienialnej między systemem kadrowo-płacowym pracodawcy KS-ZZL (zarządzanie zasobami ludzkimi) a systemami odbioru po stronie PSMP (Podmiot Służby Medycyny Pracy) oraz podmiotów medycznych (w tym KS-SOMED, KS-PPS, SERUM, Mediporta i rozwiązań innych dostawców). Profil jest prywatny dla ekosystemu KAMSOFT — nie jest przeznaczony do wymiany przez Platformę P1 i nie wymaga zgodności z polską Implementacją Krajową HL7 CDA na poziomie publikacji szablonu w CeZ.

Zakres

Dokument obejmuje wyłącznie skierowanie. Powiązane dokumenty — orzeczenie lekarskie z badania, karta badania profilaktycznego, informacja zwrotna do pracodawcy — są odrębnymi dokumentami i wymagają osobnej specyfikacji.

Podstawa prawna

Podstawa	Opis
art. 229 KP	obowiązek badań wstępnych, okresowych, kontrolnych
art. 237^15^ §2 KP	delegacja do rozporządzeń wykonawczych ws. czynników szkodliwych
Rozp. MZiOS z 30.05.1996	tryb i zakres badań profilaktycznych, wzór skierowania (zał. 3a)
Ustawa o chorobach zakaźnych	podstawa dla badań sanitarno-epidemiologicznych

Scenariusz użycia

flowchart LR
  subgraph zzl [Pracodawca · KS-ZZL]
    A1[Plugin systemowy generuje i podpisuje CDA]
    A2[Przekazuje skierowanie jako Attachment]
    A3[API.ERP transportuje Attachment]
  end
  subgraph odbior [Odbiór · PSMP i inni]
    B1[API.MED dostarcza DocumentReference]
    B2[Plugin systemowy parsuje CDA]
    B3[Rejestracja wizyty]
    B4[Orzeczenie — osobny dokument]
  end
  zzl --> odbior

02 · Architektura dokumentu

Warstwa integracji: plugin systemowy, API.ERP i API.MED

Tworzenie, konwersja, walidacja struktury i podpisywanie dokumentu CDA leży po stronie pluginu systemowego wbudowanego w KS-ZZL (strona pracodawcy). API.ERP traktuje dokument CDA jako Attachment, API.MED jako DocumentReference — obie strony przesyłają go bez analizy wewnętrznej struktury XML.

Decyzja architektoniczna
Plugin systemowy (KS-ZZL) — generuje CDA z danych HR/BHP, waliduje względem profilu KAMSOFT, podpisuje (XAdES lub bez); przekazuje gotowy dokument do API.ERP jako Attachment. API.ERP — przyjmuje Attachment, koreluje z rejestrem pracownika i pracodawcy, przekazuje do kanału wysyłki. API.MED — udostępnia dokument jako DocumentReference i dostarcza go do pluginu systemowego po stronie PSMP. Plugin systemowy (PSMP) — parsuje i waliduje CDA, identyfikuje pacjenta, rejestruje wizytę.

Warstwa	Odpowiedzialność
Plugin systemowy (KS-ZZL)	generacja CDA z danych KS-ZZL; walidacja struktury profilu; podpis elektroniczny
API.ERP	transport Attachment; korelacja z rejestrem pracownika i pracodawcy; status po stronie pracodawcy
API.MED	transport DocumentReference do pluginu systemowego PSMP; idempotencja dostarczenia
Plugin systemowy (PSMP)	parsowanie i walidacja CDA; rejestracja danych skierowania w systemie klinicznym

Konwencja ścieżek (ilustracyjnie): ERP — np. …/occupational-health/referrals lub …/mp/referrals; MED — np. …/occupational-medicine/inbound-referrals / …/intake/oh-referrals — ostateczna struktura według katalogu API KAMSOFT.

Standard bazowy

Dokument jest instancją ClinicalDocument z HL7 CDA Release 2, z rozszerzeniem polskim extPL z IK 1.3.2 wydanej przez CeZ. Wzorowany strukturalnie na szablonie Skierowanie na badanie lub leczenie (templateId 2.16.840.1.113883.3.4424.13.10.1.4, ext. 1.3.2) — z modyfikacjami wynikającymi z odmiennej semantyki autora i braku przepływu przez P1.

Profil prywatny KAMSOFT

Dokument używa własnego templateId pod KAMSOFT-owym rootem 1.2.616.1.113769. Profil nie jest publikowany w CeZ, nie wymaga walidacji w narzędziach P1 (gazelle), nie wchodzi do ścieżki IHE-XDS. Decyzje, które się z tego wynikają:

custodian wskazuje na pracodawcę (nie na CSIOZ/CeZ)
informationRecipient pominięty — w P1 to pole określa kto może pobrać dokument; u nas adresat wynika z kanału przesyłki
participant z UNDWRT (NFZ) nie występuje — badania profilaktyczne finansuje pracodawca
author nie jest lekarzem — to osoba upoważniona u pracodawcy bez numeru PWZ

Diagram uczestników nagłówka

ClinicalDocument

Nagłówek CDA	`component` · structuredBody
`recordTarget` — pracownik (PIK HL7CDA, patrz Struktura nagłówka)	Sekcja 1 · Cel badania
`author` — osoba upoważniona; `representedOrganization` = pracodawca	Sekcja 2 · Stanowisko pracy
`custodian` — pracodawca (nie CSIOZ)	Sekcja 3 · Czynniki narażenia
`legalAuthenticator` — zwykle ta sama osoba co `author`	Sekcja 4 · Wymagane badania dodatkowe
	Sekcja 5 · Informacje dodatkowe (opcjonalna)

Identyfikacja dokumentu

Kod główny 57147-1 z LOINC (Occupational medicine Referral note), z translacją na pozycję KLAS_DOK_P1 02.10 (Skierowanie na badanie lub leczenie) — dla spójności z klasyfikacją dokumentów P1, nawet jeśli dokument przez P1 nie przechodzi.

<templateId root="1.2.616.1.113769.5.1" extension="0.3"/>
<code
  code="57147-1"
  codeSystem="2.16.840.1.113883.6.1"
  codeSystemName="LOINC"
  displayName="Occupational medicine Referral note">
  <translation
    code="02.10"
    codeSystem="2.16.840.1.113883.3.4424.11.1.32"
    codeSystemName="KLAS_DOK_P1"/>
</code>

03 · Struktura nagłówka

recordTarget — pracownik

Identyfikacja pracownika zgodnie z wzorcem PIK HL7CDA. Kolejność preferencji identyfikatorów oraz schemat root dla id:

Priorytet	Identyfikator	Schemat OID (root)	Status
I	PESEL	`2.16.840.1.113883.3.4424.1.1.616`	✅ wyłącznie polski
II	Dowód osobisty (kraj wydania + numer)	`2.16.840.1.113883.3.4424.1.2.<ISO kraju>`	✅
III	Paszport (kraj wydania + numer)	`2.16.840.1.113883.4.330.<ISO kraju>`	✅
IV	Lokalny identyfikator kraju nadania	prawdopodobnie `2.16.840.1.113883.3.4424.1.1.<ISO kraju ≠ 616>` lub własna gałąź	❓ doprecyzowanie
V	Prawo jazdy	`2.16.840.1.113883.3.4424.1.3.<ISO kraju>`	✅
VI	Książeczka żeglarska	`2.16.840.1.113883.3.4424.1.5.<ISO kraju>`	✅

Symbol <ISO kraju> oznacza składową identyfikatora OID dla kraju zgodnie z PIK HL7CDA (typowo kod numeryczny ISO 3166-1 — 3 cyfry, wg aktualnego katalogu / wytycznych CeZ). W XML wartość trafia do atrybutu root jako pełny OID po podstawieniu cyfr kraju.

Opcjonalnie dodatkowy id z wewnętrznym numerem kadrowym pracownika u pracodawcy (root w gałęzi lokalnej klienta, displayable="false").

author — osoba upoważniona u pracodawcy

Konstrukcja odmienna od typowego dokumentu medycznego: assignedPerson z identyfikatorem PESEL zamiast PWZ (osoba nie jest pracownikiem ochrony zdrowia), representedOrganization = pracodawca. Brak functionCode z naszej strony — rola wystawcy (prezes, kierownik, BHP) nie jest rejestrowana przez systemy odbierające.

custodian — pracodawca

Wskazuje pracodawcę jako opiekuna dokumentu. W przeciwieństwie do dokumentów z P1, gdzie custodian to CSIOZ/CeZ.

legalAuthenticator — podpisujący

Zwykle ta sama osoba co author. Identyfikator PESEL, signatureCode="S". Faktyczny podpis (XAdES) lub jego brak — patrz Podpis i walidacja.

informationRecipient

USUNIĘTE — element pominięty świadomie. Adresat dokumentu wynika z kanału przesyłki (mail, interfejs B2B, wydruk dla pracownika), nie z treści XML.

04 · Struktura sekcji body

Pięć sekcji, z których cztery są obowiązkowe (1–4), piąta opcjonalna. Każda sekcja ma własny templateId pod gałęzią 1.2.616.1.113769.5.1.x, kod LOINC sekcji, oraz parę <text> (dla człowieka, renderowane przez XSLT) i <entry> (dla maszyny, strukturalne).

#	Sekcja	LOINC	templateId	Status
1	Cel badania	`42349-1`	`…5.1.1`	obowiązkowa
2	Stanowisko pracy	`74158-7`	`…5.1.2`	obowiązkowa
3	Czynniki narażenia	`66594-2`	`…5.1.3`	obowiązkowa
4	Wymagane badania dodatkowe	—	`…5.1.4`	obowiązkowa
5	Informacje dodatkowe	—	`…5.1.5`	opcjonalna

Sekcja 1 · Cel badania

Zawiera rodzaj badania ze słownika rodzajów badań MP (1.2.616.1.113769.1.9) oraz opcjonalnie do dwóch dat kontekstowych w entryRelationship (osobne obserwacje, kody w 1.2.616.1.113769.5.1.1): LAST-EXAM-DATE (data ostatniego badania profilaktycznego) i EXAM-VALID-UNTIL (data ważności aktualnego badania profilaktycznego). Obie daty są niezależne; przy umawianiu terminu badania MP zwykle istotniejsza jest ważność poprzedniego orzeczenia.

Kody wewnętrzne sekcji 1 (`1.2.616.1.113769.5.1.1`)

Kod	Nazwa
`LAST-EXAM-DATE`	Data ostatniego badania profilaktycznego
`EXAM-VALID-UNTIL`	Data ważności aktualnego badania profilaktycznego

Sekcja 2 · Stanowisko pracy

Kod stanowiska ze słownika ERP klienta (1.2.616.1.113769.4.z.i.w.l.81 — różny per instancja) plus opcjonalny tekstowy opis stanowiska w value xsi:type="ST". Słownik jest lokalny dla klienta; w skali ekosystemu nie ma jednego mastera.

Sekcja 3 · Czynniki narażenia

Najbardziej rozbudowana strukturalnie sekcja. Hierarchia 3-poziomowa:

organizer · BATTERY — wszystkie narażenia
organizer · CLUSTER — × 1…5 grup (słownik 1.2.616.1.113769.1.8.1); grupy: 01 fizyczne · 02 pyły · 03 toksyczne · 04 biologiczne · 05 inne
- observation · OBS — × n czynników; code: centralny 1.8.2 · lokalny 4.z.i.w.l.1.11.2 · OTH; value PQ, referenceRange, effectiveTime — opcj.; EXPOSURE-TIME, EXPOSURE-DESC — opcj.

Strategia kodowania czynników: centralny słownik KAMSOFT-u (utrzymywany przez zespół, śledzący rozporządzenia) plus możliwość wpisów lokalnych klienta. Skrajny przypadek: klient bez słownika (np. PPS) używa nullFlavor="OTH" z czystym originalText. Grupy czynników zawsze pochodzą ze słownika centralnego.

Sekcja 4 · Wymagane badania dodatkowe

Lista obserwacji z moodCode="RQO" (request). Kody pochodzą z ICD-9-PL (2.16.840.1.113883.6.103), głównie rozdziały 89.xx (konsultacje) i 95.xx (badania okulistyczne, audiologiczne). Decyzja użycia ICD-9-PL zamiast własnego słownika daje pełną zgodność z polskim państwowym katalogiem procedur.

Sekcja 5 · Informacje dodatkowe

Tekst wolny dla informacji, które nie mieszczą się w sekcjach 1–4: staż pracy, kontekst wystawienia skierowania, uwagi pracodawcy. Bez struktury <entry>.

05 · Rejestr OID i słowników

Zewnętrzne (istniejące, używamy gotowe)

Słownik / system	OID	Źródło
LOINC	`2.16.840.1.113883.6.1`	zewn.
ICD-9-PL	`2.16.840.1.113883.6.103`	zewn.
KLAS_DOK_P1	`2.16.840.1.113883.3.4424.11.1.32`	CeZ
PESEL	`2.16.840.1.113883.3.4424.1.1.616`	CeZ
REGON-9	`2.16.840.1.113883.3.4424.2.2.1`	CeZ
RPWDL (księga rejestrowa PSMP)	`2.16.840.1.113883.3.4424.2.3.1`	CeZ

KAMSOFT — gotowe (drzewo OID)

Słownik / element	OID	Status
Czynniki narażenia — centralny	`1.2.616.1.113769.1.8.2`	prod.
Grupy czynników — centralne	`1.2.616.1.113769.1.8.1`	prod.
Czynniki narażenia — lokalne klienta	`1.2.616.1.113769.4.z.i.w.l.1.11.2`	prod.
Stanowiska ERP klienta	`1.2.616.1.113769.4.z.i.w.l.81`	prod.
Pracownik (Patient)	`1.2.616.1.113769.4.z.i.w.l.10.1`	prod.
Pracodawca (Workplace)	`1.2.616.1.113769.4.z.i.w.l.16.1`	prod.
ID dokumentu (Referral)	`1.2.616.1.113769.4.z.i.w.l.15`	prod.

KAMSOFT — nadane (potwierdzone)

Potwierdzone przez właściciela drzewa OID (Tomasz Latko):

Element	OID	Status
Gałąź główna szablonów CDA	`1.2.616.1.113769.5`	nadane ✅
templateId dokumentu	`1.2.616.1.113769.5.1`	nadane ✅
templateId sekcji 1–5	`1.2.616.1.113769.5.1.[1-5]`	nadane ✅
Słownik rodzajów badania MP	`1.2.616.1.113769.1.9`	nadane ✅

Wycofane (decyzje projektowe)

Element	OID	Powód
Słownik ról wystawcy	`1.2.616.1.113769.1.10`	Rola wystawcy nie jest rejestrowana przez systemy odbierające.
Słownik badań dodatkowych	`1.2.616.1.113769.1.11`	Zastąpione ICD-9-PL (państwowy katalog procedur).

Konwencja `ValueSet.url` (FHIR) · spójnie z api-erp

W rozwiązaniach ERP KAMSOFT kanoniczny adres value setów FHIR ma postać https://api-erp.kamsoft.pl/ns/{slug}, gdzie slug jest w formacie kebab-case (jak esm-document-type, hr-inbox-document-type). Dla profilu skierowania medycyny pracy (pion mp, ang. occupational health) stosujemy prefiks value setów oh- (nie mp-). OID pozostają w CDA jako codeSystem / root; w FHIR powiązanie OID ↔ URL warto utrzymać w zasobie NamingSystem lub ValueSet.identifier.

Zasady: ValueSet.url jest stabilny (warianty wydania przez ValueSet.version, nie przez zmianę URL). Zestawy zewnętrzne (LOINC, ICD-9-PL, KLAS_DOK_P1, kody HL7 …5.*) zwykle importujemy (compose.include); osobne URL-e pod api-erp.kamsoft.pl stosujemy dla słowników własnych lub technicznych profilu lub gdy publikujemy wąski podzbiór (slice).

Proponowane `ValueSet.url` dla MP (KAMSOFT)

Publikowane w IG: źródło w repozytorium value-sets/oh-*.json (w buildzie kopiowane do /value-sets/); deploy blob: kontener name-spaces (scripts/upload-to-blob.sh).

Zakres	OID / kontekst CDA	`ValueSet.url` · artefakt IG
Rodzaj badania MP	`1.2.616.1.113769.1.9`	`oh-exam-type` · JSON
Grupy czynników narażenia	`1.2.616.1.113769.1.8.1`	`oh-exposure-group` · JSON
Czynniki — słownik centralny	`1.2.616.1.113769.1.8.2`	`oh-exposure-factor` · JSON
Kody wewnętrzne sekcji 1	`1.2.616.1.113769.5.1.1`	`oh-profile-section1-code` · JSON
Kody wewnętrzne sekcji 3	`1.2.616.1.113769.5.1.3`	`oh-profile-section3-code` · JSON
Kody wewnętrzne sekcji 4	`1.2.616.1.113769.5.1.4`	`oh-profile-section4-code` · JSON
Kody sekcji 5	`1.2.616.1.113769.5.1.5`	`oh-profile-section5-code` · JSON

Lokalne klienta (z.i.w.l) — stabilny ValueSet.url, bez pliku w IG (treść per wdrożenie):

Zakres	OID	`ValueSet.url`
Czynniki — lokalne klienta	`1.2.616.1.113769.4.z.i.w.l.1.11.2`	`https://api-erp.kamsoft.pl/ns/oh-exposure-factor-client`
Stanowiska ERP	`1.2.616.1.113769.4.z.i.w.l.81`	`https://api-erp.kamsoft.pl/ns/oh-work-position`

Zestawienie w code-systems.md §2a.

Opcjonalne zbiory „curated” nad zewnętrznym systemem (np. podzbiór LOINC dla dokumentu lub ICD-9-PL używanych procedur) można nazwać analogicznie, np. https://api-erp.kamsoft.pl/ns/oh-loinc-slice, https://api-erp.kamsoft.pl/ns/oh-icd9pl-additional-exams.

Słownik rodzajów badania MP (`1.2.616.1.113769.1.9`)

Kanoniczna definicja: oh-exam-type.json (ValueSet.url: https://api-erp.kamsoft.pl/ns/oh-exam-type).

Kod	Nazwa	Podstawa
`01`	Wstępne	art. 229 §1 KP
`02`	Okresowe	art. 229 §2 KP
`03`	Kontrolne	art. 229 §2 KP (po niezdolności >30 dni)
`04`	Końcowe	Rozp. MZ z 1996 (czynniki rakotwórcze, pyły zwłókniające)
`05`	Sanitarno-epidemiologiczne	Ustawa o chorobach zakaźnych
`06`	Celowane	kierowcy zawodowi, operatorzy, pracownicy chronieni

Grupy czynników narażenia (`1.2.616.1.113769.1.8.1`)

Kanoniczna definicja: oh-exposure-group.json.

Kod	Nazwa
`01`	Czynniki fizyczne
`02`	Pyły
`03`	Czynniki toksyczne
`04`	Czynniki biologiczne
`05`	Inne czynniki

Nazwa grupy 03 zgodna z konwencją SOMED (nie „chemiczne”, jak w rozporządzeniu MZ).

06 · Prezentacja XSLT

Dokument linkuje arkusz stylów polskiej IK CeZ:

<?xml-stylesheet href="CDA_PL_IG_1.3.2.xsl" type="text/xsl"?>

Ścieżka względna — XSLT jest dystrybuowany razem z aktualizacjami systemów medycznych KAMSOFT i powinien być dostępny lokalnie w katalogu dokumentu (w repozytorium: kanoniczna kopia w reference/CDA_PL_IG_1.3.2.xsl, symlinki obok plików XML w samples/ i tools/examples/generated/ umożliwiają podgląd w przeglądarce). Źródło aktualne: isus.ezdrowie.gov.pl.

Konwencje `<text>` dla XSLT P1

Aby render był prawidłowy, treść prezentacyjna sekcji używa wyłącznie konstrukcji obsługiwanych przez arkusz CeZ: <paragraph>, <caption>, <content ID="..."/>, <list>, <item>, <table> z thead/tbody. Kody i wartości strukturalne pozostają w <entry> i są niewidoczne dla człowieka. Każda strukturalna informacja widoczna lekarzowi musi być redundantnie wyrażona w <text>.

Decyzja prezentacyjna · sekcja 3
Tabela pięciokolumnowa (Grupa · Czynnik · Wartość zmierzona z czasem ekspozycji · NDS/NDN · Data pomiaru). Opisy dodatkowe (mikroklimat, EM, czynniki o złożonej charakterystyce) ujęte jako numerowane uwagi pod tabelą, z odsyłaczami z komórek czynnika.

07 · Podpis i walidacja

Podpis elektroniczny

Dwa scenariusze, do decyzji per wdrożenie:

XAdES-BES/T na poziomie dokumentu CDA — kwalifikowany podpis osoby upoważnionej u pracodawcy. Zgodny z eIDAS, zapewnia niezaprzeczalność.
brak podpisu elektronicznego — dokument przekazywany jest jako zwykły XML, ewentualnie z wydrukiem podpisanym ręcznie przez pracodawcę. Akceptowalne dla scenariuszy lokalnych (np. pracownik nosi wydruk do PSMP).

W obu przypadkach element <legalAuthenticator> z signatureCode="S" pozostaje w dokumencie — oznacza zamiar podpisania, niezależnie od mechanizmu.

Walidacja schematu

Wątek otwarty
Walidacja XSD dla schematu CDA + extPL będzie spełnialna na poziomie strukturalnym (zgodność z HL7 CDA R2). Dla dodatkowych reguł semantycznych (np. wymóg pewnych pól w określonych scenariuszach) może być potrzebny schematron — decyzja na czas wdrożenia.

08 · Wątki otwarte i roadmapa

Decyzje oczekujące

[Z9] PIK HL7CDA · identyfikatory pacjenta
Doprecyzowanie wyłącznie dla priorytetu IV (lokalny identyfikator kraju nadania): ostateczny wybór między wariantem …1.1.<ISO≠616> a osobną gałęzią OID — po decyzji zespołu PIK HL7CDA / CeZ zaktualizować tabelę w sekcji recordTarget.

Walidator
Decyzja architektoniczna: czy budujemy wewnętrzny walidator schematu (XSD + schematron), czy polegamy na ogólnej zgodności z HL7 CDA R2.

Plan ewolucji

Dokument generowany jest w systemie kadrowo-płacowym KS-ZZL (zarządzanie zasobami ludzkimi). Odczyt przewidziany w KS-SOMED, KS-PPS, SERUM, Mediporta oraz w systemach innych dostawców zasilających proces badania profilaktycznego u pracodawcy.

Wersja	Zakres
v0.x	iteracje robocze, dopinanie szczegółów (obecny etap); generator i szablon v0.3 w `tools/`
v0.9	kandydat produkcyjny — uzupełnione wszystkie OID-y, akceptacja zespołu, pełna lista przykładów; weryfikacja w łańcuchu KS-ZZL → odbiorcy kliniczni
v1.0	publikacja w dokumentacji wewnętrznej KAMSOFT; wdrożenie generowania w KS-ZZL (API.ERP: emisja); odczyt w KS-SOMED, KS-PPS, SERUM, Mediporta i u partnerów (API.MED: intake); integracja z kanałami (B2B / e-mail / wydruk) wg harmonogramów produktów
v1.x	rozszerzenia: dokumenty powiązane (orzeczenie, karta badania), ewentualna integracja z P1 jeśli pojawi się ścieżka

09 · Repozytorium projektu

Materiały profilu są rozłożone w katalogach względem korzenia repozytorium. Ścieżki poniżej są względem pliku tej dokumentacji (docs/).

Struktura katalogów

Katalog	Zawartość
`docs/`	Ta specyfikacja, status rejestru OID (oid-status.md)
`samples/`	Ręcznie utrzymane przykłady XML profilu MP oraz referencje P1
`reference/`	Arkusz stylów CeZ, drzewo OID KAMSOFT, słownik stanowisk i czynników
`tools/`	Generator XML v0.3 z JSON, schemat wejścia, szablony Jinja2, testy

Przykłady XML (profil MP)

Plik	Opis
samples/skierowanie_mp_v0.1.xml	Wczesna iteracja profilu (historyczna)
samples/skierowanie_mp_v0.2.xml	Scenariusz biurowy
samples/skierowanie_mp_v0.3.xml	Scenariusz hutniczy — aktualny wzorzec struktury

Referencje P1 (wzorce IG)

Pliki w samples/p1-referencje/ — dokumenty CDA z polskiej IG (OID szablonu 2.16.840.1.113883.3.4424.13.10.1.52), do porównania konwencji prezentacji i nagłówka:

…52-1.xml … …52-4.xml

Materiały pomocnicze

Plik	Opis
reference/CDA_PL_IG_1.3.2.xsl	Arkusz stylów CeZ do podglądu CDA
`reference/Stanowiska_CzynikiSzkodliwe.xlsx`	Mapowanie stanowisk i czynników szkodliwych

Generator XML v0.3

Skrypt tools/generate_skierowanie_mp.py buduje dokument zgodny z profilem v0.3 na podstawie JSON-a (schemat: tools/skierowanie_mp_input.schema.json). Przykłady wejścia i wygenerowane XML:

JSON	Wygenerowany XML	Scenariusz
`tools/examples/example_01_wstepne.json`	…/generated/example_01_wstepne.xml	Badanie wstępne
`tools/examples/example_02_przemysl.json`	…/generated/example_02_przemysl.xml	Okresowe, wiele czynników
`tools/examples/example_03_kontrolne.json`	…/generated/example_03_kontrolne.xml	Kontrolne

Instrukcja uruchomienia: tools/README.md.

Zgodność dokumentacji z kodem
Niniejsza specyfikacja opisuje profil w wersji roboczej 0.1 (treść merytoryczna). Aktualny szablon implementacyjny generatora to v0.3 (tools/templates/skierowanie_mp_v0.3.xml.j2); różnice między wersjami plików w samples/ odzwierciedlają ewolucję profilu.

Wersja dokumentacji 0.1 · skondensowana · do przeglądu wstępnego
Przykłady XML: v0.2 (biurowy), v0.3 (hutniczy) · Status OID: oid-status.md