XML Schema Browser - statusResponse Version 430

Documentation - Rev. 1
statusResponse V430

produced by Forum Datenaustausch

Permission to use, and distribute this schema and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies and the schema file is not altered.

The copyright holders make no representation about the suitability of the schema for any purpose.

It is provided "as is" without expressed or implied warranty.
The Forum Datenaustausch has endorsed this schema
as standard in the plenary meeting on 26 August 2010.

The standard becomes productive on 1st January 2011.

Copyright (©) by Forum Datenaustausch, 27.08.2010 - all rights reserved


Revision history of the documentation

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Revision history of the documentation

The following reversed chronological list shows the revision history of this documentation.

The revision history defines the time evolution of the documentation in the sense of a more precise phrasing and/or added parts.
However, the underlying statusResponse_430.xsd schema is not changed due to such an entry.
  • Revision 1 from 27.08.2010


Revision history: Documentation revision 1

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Documentation revision 1

Rev. 1/27.08.2010: the following subparts of the documentation have been refined and/or added:
  • Initial documentation of the statusResponse_430.xsd schema


Preface

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Preface

Audience of this documentation
The target audience of this documentation are primarily software developers of the Swiss healthcare sector.
An understanding of Swiss healthcare concepts (e.g. Tiers garant vs. Tiers payant and the like) as well as at least a basic knowledge about XSD schemas is presumed to be known.
How to use this documentation
There are two different views of this documentation.
  • the Hierarchical list view starts from the topmost object. By selecting a shown element one can explore the whole schema space in a recursive descent approach.
  • the Alphabetical list view is for those who are already familiar with the overall structure and concepts. As the name implies one can select from an alphabetical list of elements.

Comments and questions
Please address comments and questions concerning this documentation via either the website Forum Datenaustausch or the email address info@forum-datenaustausch.ch


Forum Datenaustausch

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Forum Datenaustausch

Im "Forum Datenaustausch" haben sich verschiedene Akteure des Schweizer Gesundheitswesens zusammengeschlossen. Das Forum verfolgt u.a. das Ziel, einheitliche, gemeinsam entwickelte Standards für den elektronischen Datenaustausch festzusetzen.

Forumsmitglieder sind die Verbände der Leistungserbringer FMH, H+ und der Schweizerische Apothekerverband (SAV), auf Seiten der Kostenträger sind es santésuisse, der Schweizerische Versicherungsverband (SVV) sowie die Suva, die Militärversicherung und die Invalidenversicherung (IV).

Die vom Forum verabschiedeten Standards, wie die XML-Nachrichten zum elektronischen Datenaustausch, werden hier publiziert. Dazu gehört auch die elektronische, XML basierende Leistungsabrechnung für Ärzte und Spitäler.

Die Gesellschaft bezweckt die Vereinheitlichung der Standards des elektronischen Datenaustausches im Schweizer Gesundheitswesen zwischen Leistungserbringern und Kostenträgern. Ziel ist die Festlegung von Grundsätzen mit Bezug auf die Übermittlungsstandards, die Referenzstammdaten sowie mit Bezug auf die Kriterien betreffend die Datensicherheit. Damit soll den Gesellschaftern der Aufbau von Kooperationsbeziehungen im Bereich des elektronischen Datenaustausches erleichtert werden.
Différents acteurs du domaine de la santé publique suisse se sont joints au "Forum Datenaustausch". L'objectif du forum consiste, entre autres, à établir des standards uniformes élaborés en commun pour l'échange électronique de données.

Les membres du forum sont les associations de prestataires FMH, H+ et la Société Suisse des Pharmaciens (SSPh) ainsi que, du côté des assureurs, santésuisse, l'Association Suisse d'Assurances (ASA), la Suva, l'assurance militaire et l'assurance invalidité (AI).

Les standards établis par le forum, tels les messages XML pour l'échange électronique de données, seront publiés ici. Ils englobent également le décompte électronique de prestations basé sur XML pour les médecins et les hôpitaux.

La société a pour but d'uniformiser les standards relatifs au transfert électronique de données dans la domaine de la santé suisse entre fournisseurs de prestations et assureurs. L'objectif consiste à déterminer des principes liés aux standards de transmission, aux données de base de référence ainsi qu'aux critères concernant la sécurité des données. Pour les membres de la société, cela devrait faciliter l'établissement de relations de coopération dans le domaine du transfert électronique de données.


Copyright (©) notice

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Copyright (©) notice

This is a normative standard for the Swiss Public Health Service

Permission to use, and distribute this schema and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies and this schema file is not altered. The copyright holders make no representation about the suitability of the schema for any purpose.

It is provided "as is" without expressed or implied warranty.


Purpose of the schema file

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Purpose of the schema file

This is the schema definition for a "Status Response" process encoded in XML. The statusResponse always constitutes an answer to a received "Status Request" which in turn querying status information about each given object reference (credit, invoice/reminder and mcd objects). In the response each object reference is given back with one assigned status valid at processing time.
The subchapter Purpose/Object reference provides an in-depth description of the concept of "object reference".

The response is sent via 1 or more intermediates to the final recipient, who is the initial sender of the request by definition. The chain of intermediates from the request is reversed for the response.

There is no concept of a response object reference but only a UNIX timestamp of the generation of the repsonse XML for legal reasons.

If an insurance decides not to support the statusRequest/statusResponse system then a statusResponse is returned where each given object reference has a status "unsupported". This status code basically signals that a status system is not implemented!

This XML project is normative for the electronic status process in Switzerland.


Conventions, terms, and definitions used

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Conventions, terms, and definitions used

This paragraph describes the conventions, terms, and definitions used in the documentation of the XSD schema files. It is assumed that the reader has at least a basic understanding of XSD schemas. Therefore, if there is an ambiguous description or insufficient documentation regarding the XSD schemas itself, you need to look up the official XSD schema definitions at W3C at http://www.w3c.org, this is especially true when using the signature and encryption mechanism.

Character entities

Since some characters in a XML infoset are forbidden these characters must be encoded via character entities. The table shows these special characters and their character entity counterparts.
& => &amp;
' => &apos;
> => &gt;
< => &lt;
" => &quot;
Basic XSD data types used
boolean | boolean has the value space required to support the mathematical concept of binary-valued logic: {true, false}. An instance of a data type that is defined as boolean can have the following legal literal value {true, false, 1, 0}.
double | The double data type corresponds to IEEE double-precision 64-bit floating point type [IEEE 754-1985]. The basic value space of double consists of the values m x 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970, inclusive.
enumeration | enumeration constrains the value space to a specified set of values.
int | int is derived from a 32bit integer by setting the value of maxInclusive and minInclusive to be 2147483647 and -2147483648.
NMTOKEN | NMTOKEN represents a token concept. The value space of NMTOKEN is the set of tokens (strings) that match the production.
pattern | pattern is a constraint on the value space of a data type, which is achieved by constraining the lexical space to literals, which match a specific pattern. The value of pattern must be a regular expression.
string | The string data type represents character strings. The value space of string is the set of finite-length sequences of characters. A character is an atomic unit of communication.


Object reference,...

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Object reference

The following paragraph define the concept of object reference. This concept is of high importance within the XML request/response system.

object reference

An object reference is an identification of an individual XML request defined by a unique triple of data, namely
  • timestamp (UNIX time) defined at the moment of generation
  • date of the object defined by the provider
  • id of the object defined by the provider
Each and every XML request of version 4.3 is defined by such an object reference. All XML responses must copy the object reference from the request, thus the object reference is a clustered primary key!


Preamble of schema file

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Preamble of schema file

The preamble of the schema file is defined as follows:
<schema targetNamespace="http://www.forum-datenaustausch.ch/status"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:status="http://www.forum-datenaustausch.ch/status"
        elementFormDefault="qualified" attributeFormDefault="unqualified">
From this definition it is evident that all elements must be qualified that is defined with the namespace tag status followed by the element name. Furthermore, the target namespace and the specific namespace status maps to http://www.forum-datenaustausch.ch/status.

Therefore, to define a correct XML infoset the elements must be defined like the following XML code snippet (for german as data language):
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<status:response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:status="http://www.forum-datenaustausch.ch/status"
        xmlns="http://www.forum-datenaustausch.ch/status"
        xsi:schemaLocation="http://www.forum-datenaustausch.ch/status statusResponse_430.xsd"
        language="de" modus="production" >
XML elements go here...

 </status:response>


Hierarchical list of used XSD definitions

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Hierarchical list of used XSD definitions

The following subchapters list all XSD definitions of the schema in hierarchical order going from the topmost element response down as the appropriate definition is encountered .


 element response
Annotation The response element is the root of the statusResponse process.
The response is divided into 2 parts
  • the processing element supplies the necessary data for the transport process
  • the payload element supplies the response to the requested querying object references
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:responseType
properties
content complex
children | status:processing status:payload
attributes parameters
Name | Type | Use | Default | Fixed
language | derived by: NMTOKEN | required |  |
modus | derived by: NMTOKEN |  | production |
attributes annotations
Name | Notes
language | language defines the used data language encoded by a terminal set of ISO language specifiers. The language used is copied from and thus defined by the request.
modus | modus defines the operating modus encoded by a terminal set of tokens
attributes enumerations
Name | Extension | Base | Value | Annotations
language |  | NMTOKEN | de | the data language is german
language |  | NMTOKEN | fr | the data language is french
language |  | NMTOKEN | it | the data language is italian
modus |  | NMTOKEN | production | the modus production (default value) is for normal processing
modus |  | NMTOKEN | test | the modus test is for software developers to test the processing.
source | <element name="response" type="status:responseType"/>


 element responseType/processing
Annotation | The processing element is a container with transport instructions basically mirrored from the request.
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:processingType
properties
isRef | 0
content | complex
children | status:transport
source | <element name="processing" type="status:processingType"/>


 element processingType/transport
Annotation The transport element defines the routing of the infoset.
In fact the meaning and the data is mirrored from the corresponding request thus the initial sender becomes the recipient and the initial recipient becomes the sender. Furthermore the chain of intermediates from the request is reversed and the infoset is sent to the first intermediate of the reversed list.
All the involved parties are defined by EAN numbers as defined by www.medwin.ch
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:transportType
properties
isRef | 0
content | complex
children | status:via
attributes parameters
Name | Type | Use | Default | Fixed
from | status:eanPartyType | required |  |
to | status:eanPartyType | required |  |
attributes annotations
Name | Notes
from | from is the EAN party that initially sent the infoset to the first intermediate. In fact this is the mirrored to attribute from the request.
to | to is the EAN party that eventually receives the infoset from the last intermediate In fact this is the mirrored from attribute from the request.
source | <element name="transport" type="status:transportType"/>


 element transportType/via
Annotation The via element defines one intermediate hop through which the infoset was routed.
It is in the responsibility of an intermediate to correctly send the infoset to the next intermediate in the mirrored list of intermediates or eventually deliver the infoset to the recipient (the sender of the request).
diagram
namespace http://www.forum-datenaustausch.ch/status
properties
isRef | 0
minOcc | 1
maxOcc | unbounded
content | complex
attributes parameters
Name | Type | Use | Default | Fixed
via | status:eanPartyType | required |  |
sequence_id | unsignedShort | required |  |
attributes annotations
Name | Notes
via | via is the EAN of an intermediate
sequence_id | sequence_id is a sequence number starting with 1 that defines a certain intermediate hop. In each new via element the sequence number is increased by 1 thus forming the mirrored chain of intermediate hops.
source <element name="via" maxOccurs="unbounded">
<complexType>
<attribute name="via" type="status:eanPartyType" use="required"/>
<attribute name="sequence_id" type="unsignedShort" use="required"/>
</complexType>
</element>


 element responseType/payload
Annotation The payload element supplies the response to the requested querying objects.
Note, that there is no ordering imposed on the object references!
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:payloadType
properties
isRef | 0
content | complex
children | status:credit status:invoice status:reminder status:mcd
attributes parameters
Name | Type | Use | Default | Fixed
response_timestamp | unsignedLong | required |  |
attributes annotations
Name | Notes
response_timestamp | response_timestamp is a UNIX timestamp defined at the moment of the response's infoset generation
source | <element name="payload" type="status:payloadType"/>


 element payloadType/credit
Annotation The credit element defines the credit object reference of the request supplemented with a status.
This element is copied from the received request
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:creditType
properties
isRef | 0
content | complex
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the credit's infoset generation This is one of 3 identifiers that form the credit object reference. request_timestamp will be generated once for a certain credit object reference and thereafter always referenced!
request_date | request_date is the main software's date of the credit request ("KoGu Falldatum") This is one of 3 identifiers that form the credit object reference. request_date must always be the same for a certain credit object reference!
request_id | request_id is the main software's ID of the credit request ("KoGu Fallnummer") This is one of 3 identifiers that form the credit object reference. request_id must always be the same for a certain credit object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted and archived.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
source | <element name="credit" type="status:creditType"/>


 element payloadType/invoice
Annotation The invoice element defines the unique invoice object reference of the request supplemented with a status.
This element is copied from the received request
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:invoiceType
properties
isRef | 0
content | complex
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
request_patient_id | status:stringType1_35 |  |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the invoice's infoset generation This is one of 3 identifiers that form the invoice object reference. request_timestamp will be generated once for a certain invoice object reference and thereafter always referenced!
request_date | request_date is the main software's date of the invoice request ("Rechnungsdatum") This is one of 3 identifiers that form the invoice object reference. request_date must always be the same for a certain invoice object reference!
request_id | request_id is the main software's ID of the invoice request ("Rechnungsnummer") This is one of 3 identifiers that form the invoice object reference. request_id must always be the same for a certain invoice object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted, archived, and the requested amount was paid to the biller.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
status |  | NMTOKEN | claimed | the status is claimed - a reimbursement process was invoked by sending back the payback information
status |  | NMTOKEN | reimbursed | the status is reimbursed - the reimbursement process was completed as the amount was paid back by the biller
source | <element name="invoice" type="status:invoiceType"/>


 element payloadType/reminder
Annotation The reminder element defines the unique reminder object reference of the request supplemented with a status.
This element is copied from the received request.
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:reminderType
properties
isRef | 0
content | complex
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the reminder's infoset generation This is one of 3 identifiers that form the reminder object reference. request_timestamp will be generated once for a certain reminder object reference and thereafter always referenced!
request_date | request_date is the main software's date of the reminder request ("Mahndatum") This is one of 3 identifiers that form the reminder object reference. request_date must always be the same for a certain reminder object reference!
request_id | request_id is the main software's ID of the reminder request ("Mahnnummer"") This is one of 3 identifiers that form the reminder object reference. request_id must always be the same for a certain reminder object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted, archived, and the requested amount was paid to the biller.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
status |  | NMTOKEN | claimed | the status is claimed - a reimbursement process was invoked by sending back the payback information
status |  | NMTOKEN | reimbursed | the status is reimbursed - the reimbursement process was completed as the amount was paid back by the biller
source | <element name="reminder" type="status:reminderType"/>


 element payloadType/mcd
Annotation The mcd element defines the unique MCD object reference of the request supplemented with a status.
This element is copied from the received request.
diagram
namespace | http://www.forum-datenaustausch.ch/status
type | status:mcdType
properties
isRef | 0
content | complex
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the MCD's infoset generation This is one of 3 identifiers that form the MCD object reference. request_timestamp will be generated once for a certain MCD object reference and thereafter always referenced!
request_date | request_date is the main software's date of the MCD request This is one of 3 identifiers that form the MCD object reference. request_date must always be the same for a certain MCD object reference!
request_id | request_id is the main software's ID of the MCD request This is one of 3 identifiers that form the MCD object reference. request_id must always be the same for a certain MCD object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted and archived.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
source | <element name="mcd" type="status:mcdType"/>


Alphabetical list of used XSD definitions

Documentation of statusResponse_430.xsd - Rev. 1

Copyright (©) by Forum Datenaustausch, 27.08.2010
All rights reserved

Alphabetical list of used XSD definitions

The following subchapters list all XSD definitions (simpleType, complexType etc.) used in the schema in alphabetical order.


 complexType creditType
diagram
namespace http://www.forum-datenaustausch.ch/status
used by
element payloadType/credit
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the credit's infoset generation This is one of 3 identifiers that form the credit object reference. request_timestamp will be generated once for a certain credit object reference and thereafter always referenced!
request_date | request_date is the main software's date of the credit request ("KoGu Falldatum") This is one of 3 identifiers that form the credit object reference. request_date must always be the same for a certain credit object reference!
request_id | request_id is the main software's ID of the credit request ("KoGu Fallnummer") This is one of 3 identifiers that form the credit object reference. request_id must always be the same for a certain credit object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted and archived.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
source <complexType name="creditType">
<attribute name="request_timestamp" type="unsignedLong" use="required"/>
<attribute name="request_date" type="dateTime" use="required"/>
<attribute name="request_id" type="status:stringType1_35" use="required"/>
<attribute name="status" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unsupported"/>
<enumeration value="unknown"/>
<enumeration value="ambiguous"/>
<enumeration value="received"/>
<enumeration value="frozen"/>
<enumeration value="processed"/>
<enumeration value="granted"/>
<enumeration value="canceled"/>
</restriction>
</simpleType>
</attribute>
</complexType>


 complexType invoiceType
diagram
namespace http://www.forum-datenaustausch.ch/status
used by
element payloadType/invoice
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
request_patient_id | status:stringType1_35 |  |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the invoice's infoset generation This is one of 3 identifiers that form the invoice object reference. request_timestamp will be generated once for a certain invoice object reference and thereafter always referenced!
request_date | request_date is the main software's date of the invoice request ("Rechnungsdatum") This is one of 3 identifiers that form the invoice object reference. request_date must always be the same for a certain invoice object reference!
request_id | request_id is the main software's ID of the invoice request ("Rechnungsnummer") This is one of 3 identifiers that form the invoice object reference. request_id must always be the same for a certain invoice object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted, archived, and the requested amount was paid to the biller.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
status |  | NMTOKEN | claimed | the status is claimed - a reimbursement process was invoked by sending back the payback information
status |  | NMTOKEN | reimbursed | the status is reimbursed - the reimbursement process was completed as the amount was paid back by the biller
source <complexType name="invoiceType">
<attribute name="request_timestamp" type="unsignedLong" use="required"/>
<attribute name="request_date" type="dateTime" use="required"/>
<attribute name="request_id" type="status:stringType1_35" use="required"/>
<attribute name="request_patient_id" type="status:stringType1_35"/>
<attribute name="status" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unsupported"/>
<enumeration value="unknown"/>
<enumeration value="ambiguous"/>
<enumeration value="received"/>
<enumeration value="frozen"/>
<enumeration value="processed"/>
<enumeration value="granted"/>
<enumeration value="canceled"/>
<enumeration value="claimed"/>
<enumeration value="reimbursed"/>
</restriction>
</simpleType>
</attribute>
</complexType>


 complexType mcdType
diagram
namespace http://www.forum-datenaustausch.ch/status
used by
element payloadType/mcd
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the MCD's infoset generation This is one of 3 identifiers that form the MCD object reference. request_timestamp will be generated once for a certain MCD object reference and thereafter always referenced!
request_date | request_date is the main software's date of the MCD request This is one of 3 identifiers that form the MCD object reference. request_date must always be the same for a certain MCD object reference!
request_id | request_id is the main software's ID of the MCD request This is one of 3 identifiers that form the MCD object reference. request_id must always be the same for a certain MCD object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted and archived.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
source <complexType name="mcdType">
<attribute name="request_timestamp" type="unsignedLong" use="required"/>
<attribute name="request_date" type="dateTime" use="required"/>
<attribute name="request_id" type="status:stringType1_35" use="required"/>
<attribute name="status" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unsupported"/>
<enumeration value="unknown"/>
<enumeration value="ambiguous"/>
<enumeration value="received"/>
<enumeration value="frozen"/>
<enumeration value="processed"/>
<enumeration value="granted"/>
<enumeration value="canceled"/>
</restriction>
</simpleType>
</attribute>
</complexType>


 complexType payloadType
diagram
namespace | http://www.forum-datenaustausch.ch/status
children | status:credit status:invoice status:reminder status:mcd
used by
element responseType/payload
attributes parameters
Name | Type | Use | Default | Fixed
response_timestamp | unsignedLong | required |  |
attributes annotations
Name | Notes
response_timestamp | response_timestamp is a UNIX timestamp defined at the moment of the response's infoset generation
source <complexType name="payloadType">
<choice maxOccurs="unbounded">
<element name="credit" type="status:creditType"/>
<element name="invoice" type="status:invoiceType"/>
<element name="reminder" type="status:reminderType"/>
<element name="mcd" type="status:mcdType"/>
</choice>
<attribute name="response_timestamp" type="unsignedLong" use="required"/>
</complexType>


 complexType processingType
diagram
namespace | http://www.forum-datenaustausch.ch/status
children | status:transport
used by
element responseType/processing
source <complexType name="processingType">
<sequence>
<element name="transport" type="status:transportType"/>
</sequence>
</complexType>


 complexType reminderType
diagram
namespace http://www.forum-datenaustausch.ch/status
used by
element payloadType/reminder
attributes parameters
Name | Type | Use | Default | Fixed
request_timestamp | unsignedLong | required |  |
request_date | dateTime | required |  |
request_id | status:stringType1_35 | required |  |
status | derived by: NMTOKEN | required |  |
attributes annotations
Name | Notes
request_timestamp | request_timestamp is a UNIX timestamp defined at the moment of the reminder's infoset generation This is one of 3 identifiers that form the reminder object reference. request_timestamp will be generated once for a certain reminder object reference and thereafter always referenced!
request_date | request_date is the main software's date of the reminder request ("Mahndatum") This is one of 3 identifiers that form the reminder object reference. request_date must always be the same for a certain reminder object reference!
request_id | request_id is the main software's ID of the reminder request ("Mahnnummer"") This is one of 3 identifiers that form the reminder object reference. request_id must always be the same for a certain reminder object reference!
status | status defines the status valid at processing time of the request encoded by a terminal set of tokens.
attributes enumerations
Name | Extension | Base | Value | Annotations
status |  | NMTOKEN | unsupported | the status is unsupported - is supplied if and only if the insurance does not support the status system.
status |  | NMTOKEN | unknown | the status is unknown - the given object reference is unknown
status |  | NMTOKEN | ambiguous | the status is ambiguous - the given object reference delivers more than one result
status |  | NMTOKEN | received | the status is received - nothing done so far except receiving the request
status |  | NMTOKEN | frozen | the status is frozen - the request is not processed until further data is provided
status |  | NMTOKEN | processed | the status is processed - the request has passed all processing and analysis
status |  | NMTOKEN | granted | the status is granted - the request is accepted, archived, and the requested amount was paid to the biller.
status |  | NMTOKEN | canceled | the status is canceled - the request is canceled and archived with reject status
status |  | NMTOKEN | claimed | the status is claimed - a reimbursement process was invoked by sending back the payback information
status |  | NMTOKEN | reimbursed | the status is reimbursed - the reimbursement process was completed as the amount was paid back by the biller
source <complexType name="reminderType">
<attribute name="request_timestamp" type="unsignedLong" use="required"/>
<attribute name="request_date" type="dateTime" use="required"/>
<attribute name="request_id" type="status:stringType1_35" use="required"/>
<attribute name="status" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="unsupported"/>
<enumeration value="unknown"/>
<enumeration value="ambiguous"/>
<enumeration value="received"/>
<enumeration value="frozen"/>
<enumeration value="processed"/>
<enumeration value="granted"/>
<enumeration value="canceled"/>
<enumeration value="claimed"/>
<enumeration value="reimbursed"/>
</restriction>
</simpleType>
</attribute>
</complexType>


 complexType responseType
diagram
namespace | http://www.forum-datenaustausch.ch/status
children | status:processing status:payload
used by
element response
attributes parameters
Name | Type | Use | Default | Fixed
language | derived by: NMTOKEN | required |  |
modus | derived by: NMTOKEN |  | production |
attributes annotations
Name | Notes
language | language defines the used data language encoded by a terminal set of ISO language specifiers. The language used is copied from and thus defined by the request.
modus | modus defines the operating modus encoded by a terminal set of tokens
attributes enumerations
Name | Extension | Base | Value | Annotations
language |  | NMTOKEN | de | the data language is german
language |  | NMTOKEN | fr | the data language is french
language |  | NMTOKEN | it | the data language is italian
modus |  | NMTOKEN | production | the modus production (default value) is for normal processing
modus |  | NMTOKEN | test | the modus test is for software developers to test the processing.
source <complexType name="responseType">
<sequence>
<element name="processing" type="status:processingType"/>
<element name="payload" type="status:payloadType"/>
</sequence>
<attribute name="language" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="de"/>
<enumeration value="fr"/>
<enumeration value="it"/>
</restriction>
</simpleType>
</attribute>
<attribute name="modus" default="production">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="production"/>
<enumeration value="test"/>
</restriction>
</simpleType>
</attribute>
</complexType>


 complexType transportType
diagram
namespace | http://www.forum-datenaustausch.ch/status
children | status:via
used by
element processingType/transport
attributes parameters
Name | Type | Use | Default | Fixed
from | status:eanPartyType | required |  |
to | status:eanPartyType | required |  |
attributes annotations
Name | Notes
from | from is the EAN party that initially sent the infoset to the first intermediate. In fact this is the mirrored to attribute from the request.
to | to is the EAN party that eventually receives the infoset from the last intermediate In fact this is the mirrored from attribute from the request.
source <complexType name="transportType">
<sequence>
<element name="via" maxOccurs="unbounded">
<complexType>
<attribute name="via" type="status:eanPartyType" use="required"/>
<attribute name="sequence_id" type="unsignedShort" use="required"/>
</complexType>
</element>
</sequence>
<attribute name="from" type="status:eanPartyType" use="required"/>
<attribute name="to" type="status:eanPartyType" use="required"/>
</complexType>


 simpleType eanPartyType
namespace | http://www.forum-datenaustausch.ch/status
type | restriction of string
used by
attributes transportType/@from transportType/@to transportType/via/@via
facets
pattern ([0-9]{13})
source <simpleType name="eanPartyType">
<restriction base="string">
<pattern value="([0-9]{13})"/>
</restriction>
</simpleType>