🇺🇸English

HPK Message Parser and Explainer

Overview

This skill parses and explains HPK (Healthcare Protocol Kernel) messages - a proprietary pipe-delimited healthcare message format used in the Hexagone system for French healthcare environments. The parser supports 100+ message types across multiple domains (patient administration, supply chain, inventory, financial, organizational), identifies message types, extracts all fields, validates structure, and provides human-readable explanations based on the official HPK dictionary and specifications.

Primary Sources of Truth :

1. HPK Dictionary (@erp-pas/hpk-dictionary) - GitLab repository with complete message schemas, field definitions, and validation rules
2. HPK ADT Message Specification - Comprehensive field definitions for patient administration messages
3. HPK GEF Specification - Workflow integration and economic/financial management messages

Coverage :

• Patient Administration : Identity (ID), Movements (MV), Coverage (CV) - 12+ message types
• Supply Chain : Products (PR), Suppliers (FO), Markets (MA), Orders (CO), Deliveries (LI), Receptions (RO) - 20+ message types
• Financial : Invoices (FA), Miscellaneous Receipts (RD) - 4+ message types
• Inventory : Stock movements (SO), Asset inventory (IM) - 5+ message types
• Organizational : Structures (ST), Users (UT) - 6+ message types
• Requests : Creation requests (DD) - 2+ message types

When to use this skill:

• Parse and explain any HPK message (raw text input from any system domain)
• Identify HPK message type and mode (ID|M1|C, MV|M2|C, PR|M0|C, etc.)
• Extract and label all HPK fields according to specification
• Validate HPK message structure, field count, and data types
• Understand HPK business rules and field mappings
• Debug HPK message issues or data quality problems
• Document HPK message examples with explanations
• Verify HPK dictionary compliance and field definitions
• Map HPK messages to HL7 v2.5 or IHE PAM equivalents
• Analyze HPK message flows in Hexagone WEB integration scenarios
• Support development of HPK message generators or parsers
• Troubleshoot Hexagone WEB to external system interfaces

HPK Message Format

HPK messages use pipe (|) as field delimiter with the following structure:

Type|Message|Mode|Emetteur|Date|User|...additional fields...

Core Fields (positions 0-5):

• Field 0 : Message Type (ID = Identity, MV = Movement, CV = Coverage)
• Field 1 : Message Code (M1, M2, M3, M6, M8, M9, MT, CE, B1, etc.)

Message Types

Identity Messages (ID|*)

ID|M1 - Patient Identity (Creation/Modification)

Purpose : Patient demographic information (registration)

Field Structure (38 fields total):

0:  Type (ID)
1:  Message (M1)
2:  Mode (C/M/D)
3:  Emetteur (Sender)
4:  Date (YYYYMMDDHHmmss)
5:  User
6:  IPP (Patient ID)
7:  Nom (Last Name)
8:  Prénom (First Name)
9:  Date de naissance (YYYYMMDD)
10: Sexe (M/F/U)
11: Adresse
12: Code postal
13: Ville
14: Pays
15: Téléphone
16: Téléphone portable
17: Email
18: Nom de naissance
19: Prénom usuel
20: Situation familiale
21: Nombre d'enfants
22: Profession
23: Médecin traitant
24: Établissement de naissance
25: Ville de naissance
26: Pays de naissance
27: Nationalité
28: INS (Identifiant National de Santé)
29: INS-C (Calcul)
30: NIR (Numéro de Sécurité Sociale)
31: Clé NIR
32: OID NIR
33: Matricule d'identité
34: Pays identité
35: Date décès (YYYYMMDD)
36: Indicateur de décès
37: Commentaire

Example :

ID|M1|C|HEXAGONE|20260122120000|USER001|PAT12345|DUPONT|JEAN|19750315|M|15 RUE DE LA PAIX|75001|PARIS|FRA|0612345678||||||||||||||||||||||||||||||

Explanation :

• Type : Identity message
• Code : M1 (Patient demographics)
• Mode : C (Creation - new patient registration)
• Patient : DUPONT JEAN, born 15/03/1975, Male
• Contact : 06 12 34 56 78, 15 RUE DE LA PAIX, 75001 PARIS, France
• System : Message from HEXAGONE system, user USER001, timestamp 22/01/2026 12:00:00

ID|MT - Treating Physician

Purpose : Assign or update patient's treating physician (médecin traitant)

Field Structure (13 fields total):

0:  Type (ID)
1:  Message (MT)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Code médecin traitant
8:  Nom médecin traitant
9:  Prénom médecin traitant
10: Spécialité
11: Date début
12: Date fin

Example :

ID|MT|C|HEXAGONE|20260122120000|USER001|PAT12345|PR_MARTIN|MARTIN|SOPHIE|CARDIOLOGUE|20260122||

Explanation :

• Type : Identity message
• Code : MT (Médecin Traitant - Treating Physician)
• Mode : C (Creation - assign new treating physician)
• Patient : PAT12345
• Physician : Dr. MARTIN SOPHIE, Cardiologist, code PR_MARTIN
• Effective : From 22/01/2026 (no end date)

ID|CE - Informed Consent

Purpose : Record patient consent for treatment/data processing

Field Structure (11 fields total):

0:  Type (ID)
1:  Message (CE)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Type consentement
8:  Statut (OUI/NON)
9:  Date début validité
10: Date fin validité

Movement Messages (MV|*)

MV|M2 - Patient Admission

Purpose : Hospital admission (admission hospitalière)

Field Structure (19 fields total):

0:  Type (MV)
1:  Message (M2)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Numéro de séjour (Visit ID)
8:  Date/heure entrée (YYYYMMDDHHmmss)
9:  Mode d'entrée (URGENCE/MUTATION/DOMICILE)
10: Établissement
11: Service
12: Unité fonctionnelle (UF)
13: Lit
14: Médecin responsable
15: Provenance
16: Type hospitalisation
17: Mode de traitement
18: Motif d'admission

Example :

MV|M2|C|HEXAGONE|20260122140000|USER001|PAT12345|VIS20260122001|20260122140000|URGENCE|CHU_PARIS|CARDIO|UF_CARDIO_01|LIT_001|PR_MARTIN|||||||

Explanation :

• Type : Movement message
• Code : M2 (Hospital admission)
• Mode : C (Creation - new admission)
• Patient : PAT12345
• Visit : VIS20260122001 (unique visit identifier)
• Admission : 22/01/2026 14:00:00 via Emergency Department
• Location : CHU_PARIS, Cardiology service, UF_CARDIO_01, Bed LIT_001
• Care Team : Attending physician PR_MARTIN

MV|M3 - Status Change

Purpose : Change in patient administrative status

Field Structure :

0-5:  Common fields (Type, Message, Mode, Emetteur, Date, User)
6:    IPP
7:    Numéro de séjour
8:    Ancien statut
9:    Nouveau statut
10:   Date changement statut
11:   Motif changement

MV|M6 - Unit Entry/Transfer

Purpose : Patient transfer between units or services

Field Structure (18 fields total):

0:  Type (MV)
1:  Message (M6)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Numéro de séjour
8:  Nouvelle UF
9:  Nouveau lit
10: Nouveau service
11: Ancienne UF
12: Ancien lit
13: Ancien service
14: Date/heure mouvement
15: Mode de transfert
16: Nouveau médecin responsable
17: Motif de transfert

Example :

MV|M6|C|HEXAGONE|20260123090000|USER002|PAT12345|VIS20260122001|UF_NEURO_01|LIT_102|NEURO|UF_CARDIO_01|LIT_001|CARDIO||||||

Explanation :

• Type : Movement message
• Code : M6 (Unit transfer)
• Mode : C (Creation - new transfer event)
• Patient : PAT12345 in visit VIS20260122001
• From : Cardiology UF_CARDIO_01, Bed LIT_001
• To : Neurology UF_NEURO_01, Bed LIT_102
• Timestamp : 23/01/2026 09:00:00

MV|M8 - Unit Exit

Purpose : Exit from functional unit (without discharge)

Field Structure :

0-5:  Common fields
6:    IPP
7:    Numéro de séjour
8:    UF de sortie
9:    Date/heure sortie UF
10:   Destination
11:   Mode de sortie

MV|M9 - Hospital Discharge

Purpose : Patient discharge from hospital

Field Structure (14 fields total):

0:  Type (MV)
1:  Message (M9)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Numéro de séjour
8:  Date/heure sortie (YYYYMMDDHHmmss)
9:  Mode de sortie (DOMICILE/MUTATION/DECES)
10: Destination
11: État à la sortie (AMELIORE/STATIONNAIRE/AGGRAVE)
12: Médecin ayant autorisé la sortie
13: Motif de sortie

Example :

MV|M9|C|HEXAGONE|20260125180000|USER003|PAT12345|VIS20260122001|20260125180000|DOMICILE||AMELIORE||||

Explanation :

• Type : Movement message
• Code : M9 (Hospital discharge)
• Mode : C (Creation - new discharge event)
• Patient : PAT12345, visit VIS20260122001
• Discharge : 25/01/2026 18:00:00
• Destination : DOMICILE (Home)
• Status : AMELIORE (Improved condition)

MV|B1 - Urgency/Box Movement

Purpose : Emergency department box movement

Field Structure :

0-5:  Common fields
6:    IPP
7:    Numéro de passage aux urgences
8:    Box de départ
9:    Box d'arrivée
10:   Date/heure mouvement
11:   Motif

MV|MT - Temporary Movement

Purpose : Temporary patient movement (exam, procedure)

Field Structure :

0-5:  Common fields
6:    IPP
7:    Numéro de séjour
8:    Lieu de départ
9:    Lieu d'arrivée
10:   Date/heure départ
11:   Date/heure retour prévue
12:   Motif (EXAMEN/BLOC/RADIOLOGIE)

Coverage Messages (CV|*)

CV|M1 - Insurance Coverage

Purpose : Patient insurance and coverage information

Field Structure (20 fields total):

0:  Type (CV)
1:  Message (M1)
2:  Mode (C/M/D)
3:  Emetteur
4:  Date
5:  User
6:  IPP
7:  Organisme payeur
8:  Code régime
9:  Caisse
10: Centre
11: Numéro adhérent
12: Clé adhérent
13: Rang bénéficiaire
14: Date début droits
15: Date fin droits
16: Type couverture (CPAM/MUTUELLE/AME)
17: Taux de remboursement
18: ALD (Affection Longue Durée)
19: CMU/CMUC

Example :

CV|M1|C|HEXAGONE|20260122120000|USER001|PAT12345|CPAM75|01|750|001|1234567890|12|00|20260101|20261231|CPAM|100|OUI|NON

Explanation :

• Type : Coverage message
• Code : M1 (Insurance information)
• Patient : PAT12345
• Insurer : CPAM 75 (Paris Social Security), code 01/750/001
• Member : #1234567890, key 12, rank 00 (primary insured)
• Validity : 01/01/2026 to 31/12/2026
• Coverage : CPAM (National Health Insurance), 100% reimbursement
• Special : ALD (Long-term condition) = YES, CMU = NO

Parsing Logic

When asked to parse an HPK message:

Step 1: Split and Identify

1. Split by pipe delimiter : fields = message.split('|')

2. Identify message type : Check fields[0], fields[1], and fields[2]

   • Type: fields[0] (ID, MV, CV, PR, FO, MA, CO, LI, RO, FA, SO, RD, IM, DD, UT, ST)
   • Message code: fields[1] (M1, M2, M3, M6, M8, M9, MT, CE, B1, etc.)
   • Mode: fields[2] (C=Creation, M=Modification, S/D=Suppression/Deletion)

3. Look up in HPK Dictionary : Use message key {Type}|{Message} to get field definitions from @erp-pas/hpk-dictionary

Step 2: Extract Base Fields

Extract standard header fields (always present in positions 0-5):

Step 3: Extract Type-Specific Fields

Based on message type, extract remaining fields:

ID|M1 (Identity - fields 6-37):

• 6: IPP (Patient ID)
• 7: Nom (Last Name)
• 8: Prénom (First Name)
• 9: Date de naissance (YYYYMMDD)
• 10: Sexe (M/F/U)
• 11-37: Additional demographic fields

MV|M2 (Admission - fields 6-18):

• 6: IPP
• 7: Numéro de séjour (Visit ID)
• 8: Date/heure entrée
• 9: Mode d'entrée
• 10-18: Location and care team details

MV|M6 (Transfer - fields 6-17):

• 6: IPP
• 7: Numéro de séjour
• 8-10: New location (UF, Bed, Service)
• 11-13: Previous location
• 14-17: Transfer details

MV|M9 (Discharge - fields 6-13):

• 6: IPP
• 7: Numéro de séjour
• 8: Date/heure sortie
• 9: Mode de sortie
• 10-13: Discharge details

CV|M1 (Coverage - fields 6-19):

• 6: IPP
• 7-19: Insurance and coverage details

Step 4: Format Data

Apply formatting based on data types:

1. Date fields (YYYYMMDD):

   • Parse: 20260122 → 22/01/2026
   • Validation: Check valid date

2. DateTime fields (YYYYMMDDHHMISSnn):

   • Parse: 20260122140530 → 22/01/2026 14:05:30
   • nn = centiseconds (usually ignored in display)

3. Enumerated values :

   • Gender: M (Male), F (Female), U (Unknown)
   • Mode: C (Creation), M (Modification), S/D (Suppression)
   • Entry modes: URGENCE, MUTATION, DOMICILE, etc.

4. Empty fields :

   • Empty string or consecutive pipes ||
   • Display as "Not provided" or leave blank

Step 5: Validate Message

Using HPK Dictionary definitions:

1. Field count validation :

   expected_count = len(dictionary[message_key].fields) actual_count = len(fields) if actual_count != expected_count: warn("Field count mismatch")

2. Required field validation :

   for field_def in dictionary[message_key].fields: if field_def.isMandatory and not fields[field_def.position]: error(f"Missing required field: {field_def.description}")

3. Type validation :

   • Date: Check format YYYYMMDD and valid date
   • Number: Check numeric and within range
   • String: Check length <= maximum

4. Length validation :

   if len(field_value) > field_def.length: warn(f"Field exceeds maximum length: {field_def.description}")

Step 6: Generate Explanation

Provide context and interpretation:

1. Message purpose : Describe what this message does
2. Operation type : Explain C/M/S/D mode
3. Key data points : Highlight important clinical/administrative data
4. Business context : Explain workflow implications
5. Related messages : Mention typical message sequences

Validation Rules

Structural Validation

1. Message format : Must start with valid Type|Message|Mode pattern
2. Uppercase header : First 6 fields must be uppercase
3. Pipe delimiter : Fields separated by | (ASCII 124)
4. No spaces : Empty fields represented as || not | |
5. Trailing pipes : May have trailing pipes for optional fields

Field-Level Validation

From HPK Dictionary isMandatory and type properties:

1. Required fields : Must not be empty if isMandatory: true
2. Date format : Must match YYYYMMDD or YYYYMMDDHHMISSnn
3. Numeric fields : Must contain only digits (and decimal point if applicable)
4. Length limits : Must not exceed length property from dictionary
5. Enumerated values : Must match allowed values (check comment field)

Business Logic Validation

From HPK specifications and business rules:

1. IPP consistency : Same IPP across related messages in a sequence
2. Visit number : MV messages for same episode must share visit number
3. Date sequences :
   • Admission date ≤ Transfer date ≤ Discharge date
   • Start date ≤ End date for coverage periods
4. Location references : Service/Unit/Bed must exist in organizational structure
5. Practitioner references : Physician codes must be valid in system

Data Quality Checks

1. Date reasonableness :

   • Birth date not in future
   • Admission date within reasonable range
   • Not more than 120 years old (unless special case)

2. Identifier formats :

   • IPP: Check format and checksum (if applicable)
   • NIR: 15 digits (13 + 2 key) with Luhn validation
   • FINESS: 9 digits for facilities

3. Code validity :

   • Gender codes: M, F, U only
   • Country codes: ISO 3166-1 alpha-3 (FRA, etc.)
   • Insurance regime codes: Check against référentiel

Error Reporting

When validation fails, report:

**Validation Issues**:
❌ **Error**: Missing required field at position 7 (Last Name)
⚠️  **Warning**: Field 9 (Birth Date) exceeds maximum length
⚠️  **Warning**: Field count mismatch - expected 38, got 35
ℹ️  **Info**: Optional field 16 (Mobile phone) not provided

Severity levels:

• Error (❌): Message cannot be processed
• Warning (⚠️): Message may have issues but can be processed
• Info (ℹ️): Optional fields or minor issues

Example Output Format

When parsing a message, provide:

### HPK Message Analysis

**Raw Message**:

[original HPK message]

**Message Identification**:
- Type: [ID/MV/CV]
- Code: [M1/M2/M6/M9/etc.]
- Full Name: [descriptive name]
- Operation: [Creation/Modification/Deletion]

**Core Fields**:
- Sender System: [emetteur]
- Timestamp: [formatted date/time]
- User: [user ID]

**[Type]-Specific Fields**:
[List all relevant fields with labels and values]

**Business Context**:
[Explain what this message represents and its purpose]

**Validation**:
- Field count: [actual] (expected: [expected for this type])
- Required fields: [✓ or ✗ for each required field]
- Date formats: [✓ or ✗]
- Enumerated values: [✓ or ✗]

HPK Dictionary Integration

GitLab Repository

Repository : https://gitlab-erp-pas.dedalus.lan/erp-pas/hexagone/hpk-dictionary
Package : @erp-pas/hpk-dictionary (NPM)
Version : 1.0.5+
Purpose : Authoritative source of truth for all HPK message definitions

Dictionary Structure

The HPK dictionary is an NPM package that provides comprehensive message definitions for the Hexagone healthcare system. Each message type includes:

{
  description: String,        // Human-readable message description
  fields: Array[{
    position: Number,         // Field position (1-based)
    description: String,      // Field description
    length: Number,          // Maximum field length
    type: String,            // Data type (String, Number, Date, etc.)
    isMandatory: Boolean,    // Required field flag
    comment: String          // Additional notes/rules
  }]
}

Dictionary Access Example

const hpk = require('@erp-pas/hpk-dictionary')

// Access message definition
const idM1 = hpk.segments['ID|M1']
console.log(idM1.description)  // "Suppression Identité Patient"

// Iterate through field definitions
idM1.fields.forEach(field => {
  console.log(`${field.position}. ${field.description} (${field.type}, max: ${field.length})`)
  if (field.isMandatory) console.log('   ⚠️  Required')
})

Message Categories in Dictionary

The HPK dictionary defines 100+ message types across these domains:

Identity & User Management (ID, UT)

• ID|M1 : Patient identity creation/modification
• ID|MT : Treating physician assignment
• ID|CE : Informed consent
• UT|A1 : User account management

Patient Movements (MV)

• MV|M2 : Hospital admission
• MV|M3 : Administrative status change
• MV|M6 : Unit/service transfer
• MV|M8 : Functional unit exit
• MV|M9 : Hospital discharge
• MV|B1 : Emergency box movement
• MV|MT : Temporary movement (exam, procedure)

Coverage & Financial (CV, FA)

• CV|M1 : Insurance coverage information
• FA|FE : Invoice header
• FA|FL : Invoice lines

Organizational Structure (ST)

• ST|EJ : Legal establishment (Établissement Juridique)
• ST|EG : Geographic establishment (Établissement Géographique)
• ST|BA : Building (Bâtiment)
• ST|ET : Floor (Étage)
• ST|CH : Room (Chambre)

Supply Chain Management (PR, FO, MA, CO, LI, RO)

• PR|M0-M5 : Product management
• FO|M1-M3 : Supplier management
• MA|M1-M3 : Contract/market management
• CO|M1-M2 : Orders
• LI|M1-M2 : External deliveries
• RO|M1-M2 : Receptions

Inventory & Stock (SO, IM)

• SO|S1 : Stock output
• SO|I1 : Inventory
• SO|T1 : Stock transfer
• SO|L1 : Pre-established lists
• IM|M1 : Asset inventory

Miscellaneous (RD, DD)

• RD|E1/L1 : Miscellaneous receipts
• DD|M1/K1 : Request messages

Using Dictionary for Validation

When parsing HPK messages, use the dictionary to:

1. Validate field count : Check actual vs. expected field count from dictionary
2. Verify required fields : Use isMandatory flag to ensure all required fields present
3. Type validation : Use type field to validate data format (Date, Number, String)
4. Length validation : Use length field to ensure values don't exceed maximum
5. Business rules : Use comment field for additional validation logic

Field Type Reference

From HPK dictionary:

• String : Text fields (alphanumeric)
• Number : Numeric fields (may include decimal precision like 9999.99)
• Date : Date fields (YYYYMMDD or YYYYMMDDHHMISSnn format)
• Boolean : True/False values (represented as T/F or O/N in French: Oui/Non)

Reference Documentation

Primary Source of Truth :

• HPK Dictionary Repository - Complete message definitions with field schemas, validation rules, and data types

Internal Documentation :

• HPK ADT Message Specification - Complete field definitions and business rules for ADT messages
• HPK GEF Specification - Workflow and integration details for economic and financial management

Related Standards (for context):

• IHE PAM 2.10 Specification: https://github.com/Interop-Sante/ihe.iti.pam.fr
• HL7 v2.5 Standard: http://www.hl7.eu/HL7v2x/v25/std25/ch02.html

Important Notes

Message Format Standards

1. First 6 fields MUST be uppercase (Type, Message, Mode, Emetteur, Date, User)
2. Pipe separator : Use | as field delimiter
3. Empty fields : Represented by consecutive pipes || (no spaces)
4. Maximum lengths : Specified in dictionary - do not exceed
5. Date format : YYYYMMDDHHMISSnn (where nn = centiseconds)

HPK to HL7 Mapping

Standard Message Mappings

HPK messages are often mapped to HL7 v2.5 / IHE PAM format for interoperability. The fixtures directory contains examples of these mappings.

Identity Messages (ID) → HL7 ADT Messages

Movement Messages (MV) → HL7 ADT Messages

Coverage Messages (CV) → HL7 Segments

Key Field Mappings

HPK ID|M1 → HL7 ADT PID Segment

HPK MV|M2 → HL7 ADT PV1 Segment

HPK MV|M9 → HL7 ADT PV1 Segment

Integration Patterns

Pattern 1: Hexagone WEB → Service Echange → External System

[Hexagone WEB] --HPK--> [Service Echange] --HPK/HL7--> [External System]
                              ↓
                        [HPK Dictionary]
                        [Mapping Rules]

Flow :

1. Event occurs in Hexagone WEB (admission, transfer, discharge)
2. HPK message generated using dictionary definitions
3. Message stored in Oracle database queue
4. Service Echange/Hexaflux processes message
5. Message transformed to HL7 (if needed) using mapping rules
6. Message sent to external system via configured connector
7. Acknowledgment received and logged

Pattern 2: External System → Hexagone WEB (Synchronous)

[External System] --Request--> [Hexagone WEB API] --HPK Event--> [Database]
                                       ↓
                                 [HPK Message]
                                       ↓
                              [Service Echange] --HPK--> [Other Systems]

Flow :

1. External system makes synchronous request to Hexagone WEB
2. Hexagone WEB processes request and updates database
3. Database trigger generates HPK message
4. Message prioritized (high priority for synchronous requests)
5. Service Echange broadcasts message to other systems
6. Response returned to original requester

Pattern 3: Message Sequencing

Typical HPK message sequences for common workflows:

New Patient Admission :

1. ID|M1|C    - Register patient identity
2. CV|M1|C    - Add insurance coverage
3. MV|M2|C    - Admit patient to hospital
4. [Optional] ID|MT|C - Assign treating physician

Patient Transfer :

1. MV|M8|C    - Exit from current unit
2. MV|M6|C    - Transfer to new unit
3. [If needed] MV|M3|C - Status change

Patient Discharge :

1. MV|M9|C    - Discharge from hospital
2. [Optional] ID|M1|M - Update address if changed
3. [Optional] CV|M1|M - Update coverage end date

OID References (French Healthcare)

Important OIDs for HPK to HL7 mapping:

Troubleshooting Common Issues

Issue 1: Field Count Mismatch

Symptom : Message has fewer/more fields than expected

Expected 38 fields for ID|M1, got 35

Causes :

• Missing trailing pipes for optional fields
• Extra pipes in text data (address, names)
• Message truncated during transmission

Solution :

1. Check HPK dictionary for expected field count
2. Verify all required fields present
3. Check for unescaped pipes in data
4. Add missing trailing pipes for optional fields

Issue 2: Date Format Errors

Symptom : Invalid date format or parsing errors

Field 9 (Birth Date): "1975/03/15" - expected YYYYMMDD

Causes :

• Wrong date format (slashes instead of numeric)
• Invalid date values (e.g., 20260231)
• Missing leading zeros

Solution :

1. Verify format is exactly YYYYMMDD (8 digits)
2. For DateTime: YYYYMMDDHHMISSnn (16 digits)
3. Validate date is real (no Feb 31, etc.)
4. Pad with zeros if needed (e.g., "2026315" → "20260315")

Issue 3: Uppercase Requirement

Symptom : Message rejected by receiver

Field 3 (Emetteur): "Hexagone" - must be uppercase

Causes :

• Mixed case in header fields (positions 0-5)
• Case sensitive validation in receiving system

Solution :

1. Convert first 6 fields to uppercase
2. Keep patient names in proper case (fields 7-8 in ID|M1)
3. Check specification for case requirements per field

Issue 4: Empty vs Missing Fields

Symptom : Required field appears empty

Field 7 (Last Name): "" - required field missing

Causes :

• Consecutive pipes || instead of value
• Space character interpreted as empty
• Null vs empty string handling

Solution :

1. For required fields: must contain non-empty value
2. For optional fields: use || (consecutive pipes)
3. Never use spaces to represent empty: | | is wrong
4. Trim whitespace from field values

Issue 5: Character Encoding

Symptom : Special characters corrupted

"Hôpital" appears as "H?pital"

Causes :

• UTF-8 vs ISO-8859-1 encoding mismatch
• Accented characters not properly encoded

Solution :

1. Verify encoding specification (usually UTF-8 or ISO-8859-1)
2. Ensure consistent encoding throughout pipeline
3. Test with accented characters: é, è, à, ô, ç
4. Consider normalization for comparison (remove accents)

Practical Usage Examples

Example 1: Parse Identity Message

Input :

ID|M1|C|HEXAGONE|20260122120000|USER001|PAT12345|DUPONT|JEAN|19750315|M|15 RUE DE LA PAIX|75001|PARIS|FRA|0612345678||||||||||||||||||||||||||||||||||||||

Expected Output :

### HPK Message Analysis

**Message Type**: ID|M1|C - Patient Identity Creation

**Core Information**:
- System: HEXAGONE
- Timestamp: 22/01/2026 12:00:00
- User: USER001
- Operation: Creation (new patient registration)

**Patient Demographics**:
- IPP: PAT12345
- Name: DUPONT JEAN
- Birth Date: 15/03/1975 (50 years old)
- Gender: Male
- Address: 15 RUE DE LA PAIX, 75001 PARIS, France
- Phone: 06 12 34 56 78

**Business Context**:
This message registers a new patient in the system. The IPP (PAT12345) will be used to identify this patient in all subsequent messages (admissions, transfers, etc.). The message was generated by USER001 on 22/01/2026 at 12:00.

**Validation**: ✓ All required fields present, correct format

Example 2: Parse Admission Message

Input :

MV|M2|C|HEXAGONE|20260122140000|USER001|PAT12345|VIS20260122001|20260122140000|URGENCE|CHU_PARIS|CARDIO|UF_CARDIO_01|LIT_001|PR_MARTIN|||||||

Expected Output :

### HPK Message Analysis

**Message Type**: MV|M2|C - Patient Admission

**Core Information**:
- System: HEXAGONE
- Timestamp: 22/01/2026 14:00:00
- User: USER001
- Operation: Creation (new admission)

**Patient & Visit**:
- IPP: PAT12345
- Visit Number: VIS20260122001
- Admission Date/Time: 22/01/2026 14:00:00

**Admission Details**:
- Entry Mode: URGENCE (Emergency admission)
- Facility: CHU_PARIS
- Service: CARDIO (Cardiology)
- Functional Unit: UF_CARDIO_01
- Bed: LIT_001
- Attending Physician: PR_MARTIN

**Business Context**:
Patient PAT12345 admitted to CHU Paris Cardiology department via emergency room on 22/01/2026 at 14:00. The visit is assigned number VIS20260122001 which will track all movements during this hospital stay. Patient assigned to bed LIT_001 in functional unit UF_CARDIO_01 under care of Dr. PR_MARTIN.

**HL7 Mapping**: Maps to ADT^A01 (Admit Patient) - IHE PAM [ITI-31]

**Validation**: ✓ All required fields present

Example 3: Parse Message Sequence

Input (Multiple Messages) :

1. ID|M1|C|HEXAGONE|20260122120000|USER001|PAT12345|DUPONT|JEAN|19750315|M|...
2. CV|M1|C|HEXAGONE|20260122120100|USER001|PAT12345|CPAM75|01|750|...
3. MV|M2|C|HEXAGONE|20260122140000|USER002|PAT12345|VIS001|20260122140000|URGENCE|...
4. MV|M6|C|HEXAGONE|20260123090000|USER003|PAT12345|VIS001|UF_NEURO|...
5. MV|M9|C|HEXAGONE|20260125180000|USER002|PAT12345|VIS001|20260125180000|DOMICILE|...

Expected Output :

### HPK Message Sequence Analysis

**Workflow**: Complete Patient Episode

**Timeline**:

**22/01/2026 12:00** - Patient Registration (ID|M1|C)
- Patient DUPONT JEAN (IPP: PAT12345) registered by USER001

**22/01/2026 12:01** - Insurance Added (CV|M1|C) [+1 min]
- CPAM Paris coverage added by USER001

**22/01/2026 14:00** - Emergency Admission (MV|M2|C) [+2h]
- Admitted via emergency, Visit: VIS001 by USER002

**23/01/2026 09:00** - Transfer (MV|M6|C) [+19h]
- Transferred to Neurology by USER003

**25/01/2026 18:00** - Discharge (MV|M9|C) [+2d 9h]
- Discharged home by USER002

**Summary**:
- Episode duration: 3 days 6 hours
- Visit VIS001 completed
- 3 users involved
- ✓ Logical sequence maintained
- ✓ Chronological order correct

**HL7 Equivalent**: ADT^A28 → ADT^A28 → ADT^A01 → ADT^A02 → ADT^A03

Quick Reference

Core Message Types

Patient Administration (ID, MV, CV)

User Management (UT)

Organizational Structure (ST)

Supply Chain - Products & Suppliers (PR, FO)

Supply Chain - Orders & Deliveries (MA, CO, LI, RO)

Financial (FA, RD)

Inventory & Stock (SO, IM)

Requests (DD)

Operation Modes

Common Field Patterns

Standard Header (all messages):

Type|Message|Mode|Emetteur|Date|User|...

Date Formats :

• Short date: YYYYMMDD (e.g., 20260122)
• Full timestamp: YYYYMMDDHHMISSnn (e.g., 20260122140530)
• nn = centiseconds (1/100 second)

Gender Codes :

• M = Male (Masculin)
• F = Female (Féminin)
• U = Unknown (Inconnu)

French Administrative Terms :

• IPP = Identifiant Permanent du Patient (Patient Permanent ID)
• INS = Identifiant National de Santé (National Health ID)
• NIR = Numéro d'Inscription au Répertoire (Social Security Number)
• UF = Unité Fonctionnelle (Functional Unit)
• FINESS = Fichier National des Établissements Sanitaires et Sociaux
• CPAM = Caisse Primaire d'Assurance Maladie (Health Insurance Fund)
• ALD = Affection Longue Durée (Long-term Condition)
• CMU = Couverture Maladie Universelle (Universal Health Coverage)

Weekly Installs

78

Repository

dedalus-erp-pas…n-skills

GitHub Stars

2

First Seen

Jan 22, 2026

Security Audits

Gen Agent Trust HubPassSocketPassSnykWarn

Installed on

codex65

gemini-cli65

github-copilot65

opencode65

cursor64

claude-code59