Hexagone Web Services Documentation -- Navigation Skill

This skill gives you access to the Hexagone Web Services documentation ("Référence Appels Externes") published as GitLab Pages. Your role is to fetch and read the relevant pages when answering questions about Hexagone web services, not to rely on memorized knowledge.

What is Hexagone swdoc

The Hexagone "Appels Externes" module (EW) exposes SOAP web services that allow external applications to invoke Hexagone Web business logic. The documentation is organized by service module (EWPT0001, EWPT0002, etc.), each grouping methods for a specific healthcare domain.

The documentation is published at:

https://erp-pas.gitlab-pages-erp-pas.dedalus.lan/hexagone/swdoc/

When to use this skill:

• The user asks about a Hexagone web service, SOAP method, or EWPT service
• The user needs to understand how to call a specific Hexagone API method
• The user is integrating with Hexagone and needs the service contract (parameters, DTDs)
• The user asks about XML DTD formats (CASE.HEXASERV, PATIENT_INFO.HEXASERV, etc.)
• The user wants to know which methods are available for a given domain (patients, movements, emergencies, etc.)
• The user is debugging an integration issue (error codes, statuts, configuration)
• The user asks about Hexagone API error codes or error handling (RESULT.HEXACALLW)
• Any question mentioning "Hexagone" combined with "web service", "API", "EWPT", "appels externes", "service web", or "WS"

Service catalog

The base URL for all pages is:

BASE_URL = https://erp-pas.gitlab-pages-erp-pas.dedalus.lan/hexagone/swdoc/

Complete service index

Method-to-service quick lookup

Use this table to quickly find which page to fetch when the user mentions a method name:

Key DTD formats

How to answer questions

Step 1: Identify the relevant page

Map the user's question to one or more service pages using the tables above:

• Specific method name (e.g., "READ_PATIENT") → use the method-to-service lookup
• Domain keyword (e.g., "patient", "urgence", "hospitalisation") → match to the service catalog
• DTD name (e.g., "CASE.HEXASERV") → use the DTD table to find the service page
• Error handling / general architecture → fetch the Introduction page
• General "list all services" → use the catalog above, no fetch needed

Step 2: Fetch the page

Use the WebFetch tool to retrieve the relevant page:

WebFetch: url="${BASE_URL}<page-path>" format="markdown"

For example:

• Introduction: WebFetch: url="https://erp-pas.gitlab-pages-erp-pas.dedalus.lan/hexagone/swdoc/00-introduction/" format="markdown"
• Patient management: WebFetch: url="https://erp-pas.gitlab-pages-erp-pas.dedalus.lan/hexagone/swdoc/01-ewpt0001-gestion-des-patients/" format="markdown"

Fetch only the page(s) you need. Do not fetch all pages at once -- each service page can be large.

If WebFetch fails (network error, timeout), inform the user that the GitLab Pages site is unreachable and suggest they access it directly in their browser.

Step 3: Extract and present the answer

After fetching, extract the relevant section from the page content:

1. For a specific method: find the Méthode <NAME> section, extract parameters, SOAP interface, and related DTD
2. For a DTD format: find the DTD <NAME> section, extract all field definitions
3. For error codes: find the Gestion des codes retour et statuts section
4. For configuration: find the Configuration de l'application section

Present the information clearly. Preserve the original structure (parameter tables, DTD field lists, error code tables) from the documentation.

Step 4: Cross-reference if needed

If the user's question spans multiple services (e.g., "how do I create an emergency case and then transfer to inpatient?"), fetch multiple pages and compose a coherent answer showing the workflow across services.

Response guidelines

When presenting web service documentation, keep the original structure from the fetched page. Hexagone web services follow a consistent pattern:

## Méthode <METHOD_NAME>

**Service:** EWPT000X – <Domain>
**Source:** [page URL]

### Description
[What the method does]

### Parameters
| Type | Name | Direction | Required | Description |
|------|------|-----------|----------|-------------|
| string | application | IN | Yes | Caller application ID |
| ... | ... | ... | ... | ... |

### SOAP Interface
[Request/Response message structure]

### Related DTD
[XML format used for data exchange]

### Error Codes
[Specific error codes for this method, if any]

### Configuration
[Required application configuration, if any]

Important rules

1. Always fetch from the GitLab Pages site -- never answer from memory or general knowledge about web services. The Hexagone API has specific conventions, SOAP-based interfaces with XML DTDs, that do not follow standard REST patterns.

2. Quote the source URL when presenting information: always mention which page the information comes from (e.g., "Source: EWPT0001 -- Gestion des patients").

3. Do not invent methods or parameters -- if the information is not found on the fetched page, say so explicitly. Do not guess or extrapolate.

4. Handle missing documentation gracefully -- if a method is not documented, inform the user and suggest they check with the Hexagone development team or open an issue in the swdoc repository at https://gitlab-erp-pas.dedalus.lan/erp-pas/hexagone/swdoc.

5. Respect the source of truth -- if there is a conflict between what the user believes and what the documentation says, trust the documentation and point out the discrepancy.

6. Cross-reference with HPK/HL7 -- if the web service relates to interoperability messages (HPK, HL7), mention the connection and suggest using the hpk-parser or hl7-pam-parser skills for message-level details.

7. Common patterns to highlight:

   • All methods require an application parameter (caller identification, configured in Hexagone Web)
   • All methods return a result buffer in RESULT.HEXACALLW format (code + status + description)
   • Code 0 = success; any other code = error (check status for details)
   • Data exchange uses XML buffers with specific DTD formats per domain
   • Application configuration (CODEGEST, PSACC, etc.) affects behavior per caller