ARMED Integration in Armenia: What Clinics Need to Check

ARMED is Armenia's state e-health system. The operator's description presents a platform exchanging clinical, administrative and financial data. Recording a visit in a clinic CRM does not mean transmitting it to ARMED. Verify the specific workflows for dental, aesthetic, hair transplant, cosmetology, diagnostic or multi-specialty clinics with the operator and responsible authorities: they may depend on services, contracts and applicable requirements.

Start with official authorisation and documentation

Before development, confirm the permitted integration route and official API availability for your situation with the operator. An employee's login is not permission for automated exchange. Request current documentation, the access procedure and a technical contact. Remember that technical connectivity alone does not confirm that a clinic meets every legal requirement that applies to it.

• Verify permitted operations and data, including necessary approvals and signatures.
• Check authentication, access scope, secret storage and access revocation procedures.
• Ask about an authorised test environment, test acceptance and approval for live connection.
• Obtain error, retry, possible limit, version change and support procedures.

Map identifiers, rather than just names

A local patient record needs an explicit, persistent link to the external record. Do not rely solely on a matching name or phone number. Use identifiers permitted by official documentation and define what happens with missing, conflicting or duplicate data. Route uncertain matches to staff review; do not merge charts by guessing. If identification is corrected later, preserve why the previous link existed and who changed it.

Similarly, check mappings for the clinic, branch, doctor, service and other required reference data against actual documentation. An internal code need not mean the same thing externally. In a multi-tenant CRM, mappings must belong to the correct clinic: another clinic's organisation identifier or credentials must never be used for transmission. Do not arbitrarily substitute a similar code for an unknown value just to make submission succeed.

A retry must not create another visit

Idempotent synchronisation means repeating an operation does not produce another duplicate result. A persistent outbound queue should link the local operation, its version and the external response. If the official API supports an idempotency key, use it as documented. Recognising the same message in your internal queue is useful, but does not itself prove that the external system cannot create a duplicate. Make that boundary explicit in testing.

A timeout does not mean nothing was saved externally: the system may have accepted the data while its response was lost. Mark the outcome as uncertain and verify acceptance through a permitted query or agreed reconciliation process. Without a confirmed duplicate prevention mechanism, do not blindly repeat creation requests. Administrators need to distinguish pending, acknowledged, rejected and uncertain operations, and know when and where to escalate a problem.

Decide what happens when systems disagree

Before launch, assign an authoritative source for each field and someone authorised to approve corrections. Simply choosing the last saved value can erase an important change. If a local visit is cancelled but has another status externally, preserve both versions and the conflict reason. Route clinical disagreements to an authorised professional. Never silently overwrite a signed medical record: link its correction to the previous version, preserving history and approval steps.

Keep an audit trail that explains transmission

An audit entry should identify the clinic, initiating user or service, time, submitted version and returned outcome. A correlation identifier should connect retries and manually resolved conflicts. Putting full clinical content, passwords and access keys in a widely accessible log is a poor solution. Define minimum necessary information, access rights, protection against changes and retention periods after checking requirements with specialists and the operator.

How MedOne approaches ARMED

In MedOne, exchange with ARMED is a separate integration module with a delivery queue, retries, mapping of patient and directory identifiers, and an audit log. Disagreements between the systems are never overwritten automatically: they go to a staff member for manual resolution, and signed medical records stay unchanged. A specific clinic is connected to ARMED once official access and documentation have been obtained from the operator.