Facility administration

Use Other without assuming a specialist package

Use the canonical Other classification with the verified shared configuration and care workflows; identify specialist requirements that still need validation.

Current source · source reviewed · 3 min read

Before you begin

Your organization has approved the facility classification and clinical scope.
An authorized administrator can create or update the facility and its related configuration.

1. Confirm the classification with the deployment owner

Choose Other only when it is the approved classification for the facility. Its version-2 native code is 3. Internal setup codes do not assert ownership, care scope or regulatory status.

2. Describe the actual service

Complete the facility identity and select only the Features that accurately describe it. Features are metadata selected independently of Facility Type; they do not create clinical staffing, active service definitions or specialist SOPs.

3. Configure the shared foundation

Set the business timezone, departments, authorized users and any required locations. Configure the activity and observation definitions and active questionnaires that the service actually uses.

4. Validate a representative permitted workflow

Use the shared patient, encounter, clinical-form, service-request, dispensing or billing workflow applicable to the configured service. Confirm the encounter types offered by your deployment. For a service request, the documented path still requires a registered patient and an encounter.

5. Record specialty requirements before rollout

Ask the service owner to review required assessments, order/result handling, access roles and outputs. Treat any missing specialist interface or procedure as an unresolved requirement rather than a capability implied by Other.

Specialist SOP boundary

No dedicated facility SOP is supplied for Other. Dental, dialysis, imaging-only, rehabilitation, home-care and other specialist applications require separate source and deployed-workflow validation; these are not extra canonical setup types.

Classification evidence

The English label is Other and the Arabic label is أخرى. This is one of the five canonical setup contract types. The catalogue does not define a separate clinical workflow implementation for this type.

Local address limitation

The audited FacilityForm uses a required six-digit numeric PIN Code validator. This is a known local-address limitation for deployments that require a different postcode format. Do not invent a postcode to bypass validation; have the deployment owner resolve the address configuration.

Troubleshooting

The expected clinical service is missing after choosing the type

Review the configured departments, activity definitions, forms, resource schedules, user roles and enabled encounter classes. The facility classification alone does not establish those records.

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.