/**
 * iCure Data Stack API Documentation
 * The iCure Data Stack Application API is the native interface to iCure. This version is obsolete, please use v2.
 *
 * OpenAPI spec version: v1
 *
 *
 * NOTE: This class is auto generated by the swagger code generator program.
 * https://github.com/swagger-api/swagger-codegen.git
 * Do not edit the class manually.
 */
import { CodeStub } from './CodeStub';
import { Delegation } from './Delegation';
import { Identifier } from './Identifier';
import { Service } from './Service';
import { SubContact } from './SubContact';
import { SecurityMetadata } from './SecurityMetadata';
import { Annotation } from "./Annotation";
import { Address } from "./Address";
import { ContactParticipant } from './ContactParticipant';
/**
 * This entity is a root-level object. It represents a contact. It is serialized in JSON and saved in the underlying icure-contact CouchDB database. The contact is the entity that records the medical information about the patient chronologically. A visit to the patient's house, a consultation at the practice, a phone call between the patient and the healthcare party or integrating lab reports into the medical file are examples of when a contact can be recorded. A contact can occur with or without direct interaction between the patient and the healthcare party. For example, when a healthcare party encodes data received from laboratory's test result, this is done in the absence of a patient. A contact groups together pieces of information collected during one single event, for one single patient and for one or more healthcare parties. Patient's complaints, the diagnosis of a new problem, a surgical procedure, etc. are collected inside a contact. The main sub-element of the contact is the service. Each atomic piece of information collected during a contact is a service and is stored inside the services list of a contact.
 */
export declare class Contact {
    constructor(json: JSON | any);
    /**
     * the Id of the contact. We encourage using either a v4 UUID or a HL7 Id.
     */
    id?: string;
    /**
     * the revision of the contact in the database, used for conflict management / optimistic locking.
     */
    rev?: string;
    /**
     * The timestamp (unix epoch in ms) of creation of this entity, will be filled automatically if missing. Not enforced by the application server.
     */
    created?: number;
    /**
     * The date (unix epoch in ms) of the latest modification of this entity, will be filled automatically if missing. Not enforced by the application server.
     */
    modified?: number;
    /**
     * The id of the User that has created this entity, will be filled automatically if missing. Not enforced by the application server.
     */
    author?: string;
    /**
     * The id of the HealthcareParty that is responsible for this entity, will be filled automatically if missing. Not enforced by the application server.
     */
    responsible?: string;
    /**
     * The id of the medical location where this entity was created.
     */
    medicalLocationId?: string;
    /**
     * A tag is an item from a codification system that qualifies an entity as being member of a certain class, whatever the value it might have taken. If the tag qualifies the content of a field, it means that whatever the content of the field, the tag will always apply. For example, the label of a field is qualified using a tag. LOINC is a codification system typically used for tags.
     */
    tags?: Array<CodeStub>;
    /**
     * A code is an item from a codification system that qualifies the content of this entity. SNOMED-CT, ICPC-2 or ICD-10 codifications systems can be used for codes
     */
    codes?: Array<CodeStub>;
    /**
     * The identifiers of the Contact
     */
    identifier?: Array<Identifier>;
    /**
     * Soft delete (unix epoch in ms) timestamp of the object.
     */
    endOfLife?: number;
    /**
     * hard delete (unix epoch in ms) timestamp of the object. Filled automatically when deletePatient is called.
     */
    deletionDate?: number;
    /**
     * Separate contacts can merged in one logical contact if they share the same groupId. When a contact must be split to selectively assign rights to healthcare parties, the split contacts all share the same groupId
     */
    groupId?: string;
    /**
     * The date (YYYYMMDDhhmmss) of the start of the contact.
     */
    openingDate?: number;
    /**
     * The date (YYYYMMDDhhmmss) marking the end of the contact.
     */
    closingDate?: number;
    /**
     * Description of the contact
     */
    descr?: string;
    /**
     * Location where the contact was recorded.
     */
    location?: string;
    /**
     * An external (from another source) id with no guarantee or requirement for unicity.
     */
    externalId?: string;
    /**
     * The location where the encounter took place
     */
    encounterLocation?: Address;
    encounterType?: CodeStub;
    /**
     * Set of all sub-contacts recorded during the given contact. Sub-contacts are used to link services embedded inside this contact to healthcare elements, healthcare approaches and/or forms.
     */
    subContacts?: Array<SubContact>;
    /**
     * Set of all services provided to the patient during the contact.
     */
    services?: Array<Service>;
    /**
     * The participants to the contact. The key is the type of participant, the value is the id of the participant data owner id
     * @deprecated use participantList
     */
    participants?: Record<ParticipantType, string>;
    participantList?: Array<ContactParticipant>;
    healthcarePartyId?: string;
    modifiedContactId?: string;
    /**
     * The secretForeignKeys are filled at the to many end of a one to many relationship (for example inside Contact for the Patient -> Contacts relationship). Used when we want to find all contacts for a specific patient. These keys are in clear. You can have several to partition the medical document space.
     */
    secretForeignKeys?: Array<string>;
    /**
     * The secretForeignKeys are filled at the to many end of a one to many relationship (for example inside Contact for the Patient -> Contacts relationship). Used when we want to find the patient for a specific contact. These keys are the encrypted id (using the hcParty key for the delegate) that can be found in clear inside the patient. ids encrypted using the hcParty keys.
     */
    cryptedForeignKeys?: {
        [key: string]: Array<Delegation>;
    };
    /**
     * When a document is created, the responsible generates a cryptographically random master key (never to be used for something else than referencing from other entities). He/she encrypts it using his own AES exchange key and stores it as a delegation. The responsible is thus always in the delegations as well
     */
    delegations?: {
        [key: string]: Array<Delegation>;
    };
    /**
     * When a document needs to be encrypted, the responsible generates a cryptographically random master key (different from the delegation key, never to appear in clear anywhere in the db. He/she encrypts it using his own AES exchange key and stores it as a delegation
     */
    encryptionKeys?: {
        [key: string]: Array<Delegation>;
    };
    /**
     * The base64 encoded data of this object, formatted as JSON and encrypted in AES using the random master key from encryptionKeys.
     */
    encryptedSelf?: string;
    securityMetadata?: SecurityMetadata;
    /**
     * Comments - Notes recorded by a HCP about this service
     */
    notes?: Array<Annotation>;
}
export type ParticipantType = 'admitter' | 'attender' | 'callback' | 'consultant' | 'discharger' | 'escort' | 'referrer' | 'secondaryPerformer' | 'primaryPerformer' | 'participation' | 'translator' | 'emergency' | 'location' | 'recorder';