Profile kanoniczne
Ta część przewodnika zbiera to, jak opisujemy zasoby kanoniczne w praktyce: które pola są obowiązkowe, jak wygląda struktura w JSON oraz — tam, gdzie to ma sens — jak pole łączy się z listą dozwolonych kodów (ValueSet). Chodzi o czytelny, wspólny opis ograniczeń i powiązań z listami kodów — wyłącznie w kontekście API.ERP i standardu Kamsoft.FAIR.
Pliki JSON poniżej to podgląd z aktualnej wersji modeli kanonicznych opisanych w tym Implementation Guide — pola i kardynalności są z nimi spójne. Integrator stosuje dostarczony zestaw plików z tej samej wersji IG i API co używane kontrakty (OpenAPI, JSON Schema); nie edytuj ich ręcznie — modyfikacje po stronie integratora nie stanowią części kontraktu z operatorem API.
Profile w formacie JSON
Jak czytać te pliki
- Ścieżki pól odpowiadają nazwom z kontraktu API (OpenAPI / JSON Schema w kanonie EOD), np. kolekcja pozycji faktury to ścieżka w stylu
Invoice.lines, zgodnie z publikowanym kontraktem (bez aliasów spoza API). - Dla pól opartych o CodeableConcept w profilu pojawi się powiązanie z ValueSet: identyfikator
urljest ten sam, co w artefaktach IG i w rozdziale o systemach kodów. - W JSON profilu pole
bindingpodaje tylko identyfikator ValueSet (valueSetjako URI). Pola dodatkowe (np. siła wymuszenia listy kodów) nie występują w tym artefakcie — ewentualne wymagania dodatkowe są w kontrakcie API dla wybranej wersji.