Extensions

DRG / Casemix / Grouper Integration

Review coding and casemix responsibilities with precise boundaries.

Prepare coded episode

Identify the encounter and approved coding inputs required by the selected grouper. Review diagnosis, procedure and episode completeness with the coding owner before grouping.

  • Clinical coding team
  • Episode reference, coding inputs and completeness review
View the full workflow
01 / 04
01

DRG / Casemix / Grouper Integration

From the first action to the final record.

01

Prepare coded episode

Identify the encounter and approved coding inputs required by the selected grouper. Review diagnosis, procedure and episode completeness with the coding owner before grouping.

Responsible team
Clinical coding team
Data & records
Episode reference, coding inputs and completeness review
02

Agree the grouper

Confirm the grouper release, licence, supported input format and delivery route. Establish whether processing is external or supplied in the accepted deployment; test representative coded cases.

Responsible team
Coding and integration owner
Data & records
Grouper version, licence, mapping and test evidence
03

Review grouping output

Keep the returned grouping result with its episode, input version and review responsibility. Validate errors and unexpected group assignments before using the result in casemix analysis.

Responsible team
Casemix reviewer
Data & records
Grouping result, input version and review evidence
04

Correct & compare

Preserve previous results when coding is corrected or a grouper version changes. Agree financial use and reporting definitions separately, then re-test representative episodes after changes.

Responsible team
Coding, analytics and finance
Data & records
Correction reason, result versions and approved reporting use
02

Your configuration

The data that makes this module yours.

  1. Download the template for your account’s selected release.
  2. Use the sample to understand formats; replace every example with approved data.
  3. Load parent records first, then use their exact identifiers in dependent files.
  4. Upload in the named setup step, fix validation errors and review the preview.
  5. Apply and save; test the workflow and record approval before activation.
Your organizationorganization.csvAccount configuration

Use the registered details of your organization. Do not enter patient records here.

Upload in the matching account setup step, review the preview, apply the values and Save and continue. The tenant version may define different columns; download its template inside setup.

Columns, formats and example values
ColumnRequiredFormatExample
Registered organization namelegal_nameYestextExample Healthcare Organization
Commercial registration numberregistration_numberYestextEXAMPLE-CR-001
CountrycountryYesSA / AE / BH / KW / QA / OM / EG / OTHERSA
Tax registration numbervat_numberOptionaltext—
Facilitiesfacilities.csvAccount configuration

Add every facility included in your subscription. These become real, separate facilities in your app.

Upload in the matching account setup step, review the preview, apply the values and Save and continue. The tenant version may define different columns; download its template inside setup.

Load / review first: Your organization

Columns, formats and example values
ColumnRequiredFormatExample
Facility namenameYestextExample Facility
Facility typetypeYeshospital / clinic / polyclinic / laboratory / otherclinic
Facility licenselicense_numberYestextEXAMPLE-LICENSE-001
AddressaddressYestextExample training address
PhonephoneYestext+966500000000
Time zonetimezoneYesAsia/Riyadh / Asia/Dubai / Asia/Qatar / Africa/Cairo / UTCAsia/Riyadh
Departmentsdepartments.csvAccount configuration

Create departments, consultation rooms, wards and beds. You can add more inside your app.

Upload in the matching account setup step, review the preview, apply the values and Save and continue. The tenant version may define different columns; download its template inside setup.

Load / review first: Facilities

Columns, formats and example values
ColumnRequiredFormatExample
Facility number (starting at 1)facilityYesinteger 1–10001
Department namenameYestextExample Department
Rooms, wards and bedslocations.csvAccount configuration

Create departments, consultation rooms, wards and beds. You can add more inside your app.

Upload in the matching account setup step, review the preview, apply the values and Save and continue. The tenant version may define different columns; download its template inside setup.

Load / review first: Facilities

Columns, formats and example values
ColumnRequiredFormatExample
Facility numberfacilityYesinteger 1–10001
Location namenameYestextExample Room
TypekindYesroom / ward / bedroom
Inside location (optional)parentOptionaltext—
Planned teamstaff.csvAccount configuration

Your verified account becomes the facility administrator. Invite staff in the account portal; staff seats are enforced.

Upload in the matching account setup step, review the preview, apply the values and Save and continue. The tenant version may define different columns; download its template inside setup.

Columns, formats and example values
ColumnRequiredFormatExample
NamenameYestextExample Staff
Work emailemailYesemailstaff@example.invalid
Clinical roleroleYesfacility_admin / doctor / nurse / pharmacist / reception / billing / memberdoctor
Function settings · scheduling closuresproduct_settings.csvAccount configuration

Registry function settings applied to native scheduling closures with readback

Upload in Your products · configuration data. Apply, then Save and continue checks cross-file references. Launch imports supported records in one transaction and reconciles counts. Function settings are validated against the supported registry, applied natively and read back; prices, catalogue mappings and hardware require approval before activation.

Load / review first: Rooms, wards and beds

Columns, formats and example values
ColumnRequiredFormatExample
Facility numberfacilityYesinteger 1–10001
Selected feature IDfeatureYesschedulingscheduling
Function settingfunction_keyYesscheduling.closuresscheduling.closures
Closure namenameYestextExample closure
First closed datevalid_fromYesYYYY-MM-DD2026-12-01
Last closed datevalid_toYesYYYY-MM-DD2026-12-01
Closed fromstart_timeYesHH:MM08:00
Closed untilend_timeYesHH:MM17:00
Room (blank closes the whole facility)locationOptionaltextExample Room
Project scopeproject_scope.csvImplementation record

Freeze products, versions, facilities, delivery mode and acceptance scope.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Columns, formats and example values
ColumnRequiredFormatExample
Catalogue product IDproduct_idYestextoutpatient
Agreed releasereleaseYestextTO-CONFIRM
Operating modemodeYesnative / connectednative
Facility scopefacility_scopeYestextall
Included in this projectincludedYestrue / falsetrue
Accountable roleowner_roleYestextProject owner
Acceptance evidenceacceptance_testYestextApproved end-to-end test
Approval referenceapproval_referenceYestextEXAMPLE-REF-001
Assumptions & decisionsassumptions_decisions.csvImplementation record

Keep each unresolved assumption visible with an owner and closure test.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Load / review first: Project scope

Columns, formats and example values
ColumnRequiredFormatExample
Decision IDdecision_idYestextDEC-001
TopictopicYestextLegacy records
Proposed assumptionassumptionYestextNo historical patient import until approved
StatusstatusYesproposed / approved / rejected / openproposed
Decision ownerowner_roleYestextData owner
Evidence referenceevidence_referenceYestextEXAMPLE-REF-001
Impact if wrongimpact_if_wrongYestextMigration scope must change
Closure testclosure_testYestextSource inventory approved
Access & approvalsaccess_matrix.csvImplementation record

Map roles to permitted actions and verify access across facility boundaries.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Load / review first: Facilities · Planned team

Columns, formats and example values
ColumnRequiredFormatExample
RoleroleYestextdoctor
Facility scopefacility_scopeYestextEXAMPLE-FACILITY-001
ResourceresourceYestextPatient record
ActionactionYestextread
AllowedallowedYestrue / falsetrue
Approverapprover_roleYestextSecurity owner
Test evidenceevidence_referenceYestextEXAMPLE-REF-001
Service catalogueservice_catalogue.csvMigration preparation

Define services and approved code mappings before orders, tariffs and interfaces.

Upload this preparation file in Account setup → Implementation files & acceptance evidence. It is saved in your account records. Use the secure migration workspace for actual clinical data. Approve the source-to-target mapping and import adapter for the selected release before any load. Run a dry run, reconcile counts and retain the result log.

Load / review first: Departments

Columns, formats and example values
ColumnRequiredFormatExample
Local service codeservice_codeYestextEXAMPLE-SVC-001
English namename_enYestextExample service
Arabic namename_arYestextخدمة تدريبية
Department codedepartment_codeYestextEXAMPLE-DEPT-001
Unit of serviceunitYestextTO-CONFIRM
Code systemcode_systemYestextTO-CONFIRM
Catalogue releasereleaseYestextTO-CONFIRM
Approved external mappingexternal_codeYestextTO-CONFIRM
Effective fromeffective_fromYesYYYY-MM-DD2026-10-09
Clinical workflow configurationclinical_workflows.csvImplementation record

Record locally approved pathways, responsibilities and exception handling.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Load / review first: Departments · Access & approvals

Columns, formats and example values
ColumnRequiredFormatExample
Workflow IDworkflow_idYestextEXAMPLE-WF-001
Product IDproduct_idYestextoutpatient
Entry evententry_eventYestextPatient arrival
Responsible roleresponsible_roleYestextNurse
Required informationrequired_informationYestextVerified identity and visit context
Next eventnext_eventYestextClinical consultation
Handover ownerhandover_ownerYestextDoctor
Exception pathexception_pathYestextIdentity mismatch to review
Workflow approvalapproval_referenceYestextEXAMPLE-REF-001
Interface specificationinterfaces.csvImplementation record

Define the agreed message contract. Store references to credentials, never the credentials themselves.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Load / review first: Facilities · Service catalogue · Existing systems & versions

Columns, formats and example values
ColumnRequiredFormatExample
Interface IDinterface_idYestextEXAMPLE-IF-001
Source systemsource_systemYestextSRC-EPIC-001
Target systemtarget_systemYestextMANSOQ
DirectiondirectionYesinbound / outbound / bidirectionalinbound
Protocol and versionprotocol_versionYestextTO-CONFIRM
Message scopemessage_scopeYestextTO-CONFIRM
Identifier mappingidentifier_mappingYestextTO-CONFIRM
Secret manager referencesecret_referenceYestextREFERENCE-ONLY
Retry and duplicate policyretry_policyYestextTO-CONFIRM
Failure ownerfailure_ownerYestextIntegration owner
Test evidencetest_referenceYestextEXAMPLE-REF-001
Acceptance testsuat_cases.csvImplementation record

Record complete positive, negative, boundary, access and failure tests per product.

Upload in Account setup → Implementation files & acceptance evidence. The data is saved in your account implementation records. Review with the named owner, record approval and attach the evidence. This register records decisions; it does not activate production configuration.

Load / review first: Project scope · Clinical workflow configuration

Columns, formats and example values
ColumnRequiredFormatExample
Test IDtest_idYestextUAT-001
Product IDproduct_idYestextoutpatient
ScenarioscenarioYestextVisit from arrival to financial follow-up
PreconditionspreconditionsYestextApproved setup and synthetic data
Exact actionsactionsYestextTO-CONFIRM
Expected resultexpected_resultYestextTO-CONFIRM
Actual resultactual_resultYestextNOT-RUN
StatusstatusYesnot_run / pass / fail / blockednot_run
Evidence referenceevidence_referenceYestextEXAMPLE-REF-001
Approverapprover_roleYestextProduct owner
Existing systems & versionssource_systems.csvImplementation record

Inventory every source EHR, department system, archive and ERP separately, including the exact installed product and licensed extraction route.

Upload this planning CSV in Account setup → Implementation files & acceptance evidence. Preview, apply and save. Keep source clinical files and identity crosswalk records in the approved secure migration workspace. Record actual evidence references after review; this register does not run a vendor connector or import patient history.

Load / review first: Project scope

Columns, formats and example values
ColumnRequiredFormatExample
System IDsystem_idYestextSRC-EPIC-001
VendorvendorYestextEpic
Installed productproductYestextEpic EHR
Installed releasereleaseYestextTO-CONFIRM
EnvironmentenvironmentYestest / production / archivetest
Facilities coveredfacility_scopeYestextEXAMPLE-FACILITY-001
Source administrator rolesource_ownerYestextSource EHR administrator
Approved extraction routeexport_routeYestextEHI export assessment pending
Licence/access evidencelicence_referenceYestextEXAMPLE-REF-001
Release-specific specificationspecification_referenceYestexthttps://open.epic.com/TechnicalSpecifications
Open the full implementation handbook: assumptions, migration, interfaces, acceptance and cutover
03

Illustrative operating cases

Two cases. Every handover explained.

01Illustrative scenario

Accepted coded episode to casemix review

Coding staff prepare an episode for the selected licensed grouper and analytics review.

Prepare first
Complete coded inputs, episode identifier, grouper licence and version and approved processing route.
  1. Review episode and coding completeness against the selected grouper inputs.
  2. Send or process the accepted input through the agreed integration route.
  3. Link the returned result to its episode and input version and review exceptions.
  4. Use only accepted results in the agreed casemix view and approved financial scope.

Acceptance evidence

The result is reproducible from the identified inputs and grouper version.

02Illustrative scenario

Coding correction across a grouper upgrade

An episode is corrected while reporting moves to another accepted grouper version.

Prepare first
Prior inputs and results, correction reason, both versions and reporting approval.
  1. Preserve the original episode inputs and grouping result.
  2. Have the coding reviewer approve the corrected clinical inputs.
  3. Compare outputs using the accepted versions and explain differences.
  4. Approve the reporting effect and retain both historical and corrected result references.

Acceptance evidence

A changed group is attributable to coding or version changes rather than an unexplained overwrite.

04

Worked operating scenarios

When the normal path changes.

Incomplete coding inputs

Return the episode to the named coding reviewer and record missing inputs instead of accepting an unsupported group.

Output changes after grouper upgrade

Compare the same accepted inputs across versions, explain differences and approve the reporting impact.

05

Delivery boundary

Know what connects, and what needs approval.

DRG capability requires an agreed licensed grouper and supported integration. No particular grouper, national reimbursement rule or automatic financial outcome is implied.

Operating modes
Native · Connected
Product readiness
Scope review required for your release
Supported release
Confirm in the accepted scope

Your questions, answered.

What does MANSOQ DRG / Casemix / Grouper Integration cover?

Defined coding/casemix workflow, supported grouper release, licensing and interfaces; catalogue access does not imply an active grouper license. Prepare coded episode: Identify the encounter and approved coding inputs required by the selected grouper. Review diagnosis, procedure and episode completeness with the coding owner before grouping. Agree the grouper: Confirm the grouper release, licence, supported input format and delivery route. Establish whether processing is external or supplied in the accepted deployment; test representative coded cases. Review grouping output: Keep the returned grouping result with its episode, input version and review responsibility. Validate errors and unexpected group assignments before using the result in casemix analysis. Correct & compare: Preserve previous results when coding is corrected or a grouper version changes. Agree financial use and reporting definitions separately, then re-test representative episodes after changes.

Explore the details
What setup data does DRG / Casemix / Grouper Integration need?

Configure the selected release using the account templates, then validate references and preview before import. Required planning and setup files include Clinical workflow configuration (clinical_workflows.csv); Interface specification (interfaces.csv); Assumptions & decisions (assumptions_decisions.csv); Function settings · scheduling closures (product_settings.csv); Acceptance tests (uat_cases.csv). Each file’s field guide identifies whether it imports setup records or documents a migration/decision.

Explore the details
How does DRG / Casemix / Grouper Integration handle exceptions?

Incomplete coding inputs Return the episode to the named coding reviewer and record missing inputs instead of accepting an unsupported group. Output changes after grouper upgrade Compare the same accepted inputs across versions, explain differences and approve the reporting impact.

Explore the details
How does DRG / Casemix / Grouper Integration connect with other systems?

DRG capability requires an agreed licensed grouper and supported integration. No particular grouper, national reimbursement rule or automatic financial outcome is implied.

Explore the details
Explore all frequently asked questions