Medical Review

At times, it is required to collect certain information from a system, for example a document management system or a system of record for provider contracts. Based on the information returned by the external system, pend rules or validation rules can be triggered to help the system make appropriate decisions regarding the request.

Another important need of the processing is to have an ability to send out notifications to an external system so that a parallel business rocess can be triggered.

In this example, a callout rule - which helps in gathering information from an external system - and an event rule - which helps in sending out notifications to an external system - are explained.

The process step is configured as:

Process Step	Rule Step
Medical Review	Validation Rule	Combination Check
	Callout Rule	Fetch Documentation Details
	Event Rule	Submit Diagnostic Documentation
	Pend Rule	Missing Diagnostic Documentation

The validation rule 'Combination Check' is to check that if a certain procedure is requested, there should also be accompanying diagnostic details. Such a mapping can be maintained through a reference sheet (for more detail on reference sheets see the example on pricing check and benefits check). If the diagnostic details are absent in the request a message is attached to the authorization.

Certain procedures also require that copies of diagnostic reports are made available. The system needs to know

• if documents related to all required diagnoses are submitted or not

• which documents are missing.

To achieve this, the system needs to make a callout to an external document management system.

The callout rule is configured as:

Field	Value
Code	CALL_DOCSYS
Description	Fetch information on diagnostic reports submitted by requester
Condition	DYLO_CAL_DOCSYS
Function	DYLO_CAL_DOCSYS
Display in UI?	Y
Enabled?	Y

Condition DYLO_CAL_DOCSYS checks the following:

• Has the 'Combination Check' passed?

• Does an authorization procedure belong to the list of procedures for which diagnostic reports must be submitted?

Dynamic logic function DYLO_CAL_DOCSYS is implemented such that it generates the following request:

<authorization
  code=''
  >
  <diagnoses>
    <diagnosis code =''>
    ...
  </diagnoses>
</authorization>

The authorization diagnoses entity is extended by a dynamic field - 'Documents Submitted?' to capture the details returned by the document management system. This field is set to 'Yes' during processing of the callout response when necessary documents are present in the external system, otherwise it is set to 'No'.

Dynamic logic function DYLO_CAL_DOCSYS is implemented so that it expects the response from the document management system in the following structure

<authorization
  code=''
  >
  <diagnoses>
    <diagnosis code ='' documents ='Y'> -- gives 'Y'/'N'
    ...
  </diagnoses>
</authorization>

Based on the response from the external system, dynamic field 'Documents Submitted?' on each diagnosis gets an appropriate value. The function dynamic logic also adds message 'MSG_DOC_MISSING' to the authorization when documents are missing. This message is then a trigger for event rule EVE_DOCMISSING so that the requester can be contacted through some correspondence mechanism and he/she can provide necessary details.

The event rule is configured as:

Field	Value
Code	EVE_DOCMISSING
Topic	DOCUMENT MISSING
Event	DOCUMENT MISSING
Authorization Type	-
Authorization Form	-
Message Group	DOC_MISSING_GRP Note that message MSG_DOC_MISSING is supposed to be added to the message group 'DOC_MISSING_GRP'
Service Type	-
Procedure Group	-
Diagnosis Group	-
Condition	-
Authorization Fields	DOC_MISSING_FIELDS
Reraise Event?	Y
Log Event?	Y
Display in UI?	Y
Enabled?	Y

Here dynamic logic DOC_MISSING_FIELDS is configured so that the Event Rule based Event message (through Outbound Restful Service Invocation) is sent out with the fields containing information on the missing diagnoses. The event message looks like:

<defaultNotificationEvent topic="DOCUMENT MISSING" type="DOCUMENT MISSING" >
   <links>
       <link rel="operator:subject" href="http://[host:port]/api/authorizations/1234"/>
      ...
   </links>
   <diagnoses><![CDATA[ List of diagnoses for which documents are not available]]></diagnoses>
   <requestedForInsurableEntity><![CDATA[ Details of insurable entity]]></requestedForInsurableEntity>
   <requestedBy><![CDATA[ Details of requester]]></requestedBy>
</defaultNotificationEvent>

A pend rule is triggered if the message 'MSG_DOC_MISSING' is attached. The pend rule is configured as

Field	Value
Code	PEND_DOC_MISSING
Description	Pend for missing documents
Authorization Type	-
Authorization Form	-
Brand	-
Message	MSG_DOC_MISSING
Message Group	-
Service Type	-
Procedure Group	-
Diagnosis Group	-
Condition	-
Pend Reason	DOC_MISSING_CHECK
Suppress When Fatal?	Y
Enabled?	Y

The callout rule is triggered only when the necessary diagnostic information is present on the authorization, the outcome of the callout rule drives the event and pend rule.

The images below show the following situations:

1. When the Combination Check fails and a fatal message is attached

2. When the Combination Check passes, but the documents are missing

Image #1:

Image #2

What if?

If missing diagnostic information should not lead to automatic denial of the authorization but should force the authorization for manual intervention then:

1. The pend rule can be configured to check for both the messages: if either of them is present the authorization will pend. This can be done by adding the validation message to DOC_MISSING_GRP and the pend rule should now have message group DOC_MISSING_GRP as fixed criterion. Two pend rules can be configured. This option can further provide more flexibility in terms of reattaching a pend reason. It might not be of interest to pend the authorization again if the requester has provided valid reasons for not being able to submit documentation. However, this may not apply for the missing diagnostic information during reprocessing because in this case it is required to pend the authorization.

The system offers the possibility to configure processing variations by implementing the rules in different ways and this helps to realize various business use cases.