Procedures
Oracle Health Insurance applications store each procedure in a two layer structure, that is, a procedure record and one or more procedure setting records. The reason is that the properties of a procedure may change over time. However, from a set up point of view, it is still the same procedure. Having the two layers precludes the configuration users from having to update / add procedure codes to the configuration that relies on the procedure codes (e.g. benefit specifications) every time a procedure property changes.
It is possible to group procedures in procedure groups and baskets.
Procedure
Field | Description |
---|---|
Code |
The code for this procedure |
Description |
The description of the procedure |
Flex Code Definition Code |
The definition to which the procedure belongs. |
Start Date |
The first day that this procedure can be used |
End Date |
The last day that this procedure can be used |
Display Access Restriction |
The access restriction restricting access to this procedure. See the chapter on data access restriction features in the User Access chapter in the Security Guide. |
The flex code definition code is the qualifier of the procedure code. The available definitions can be part of the seeded configuration or can be setup by a configuration user. An example: a procedure with the code '30.22', the description 'Excision of vocal cords' and the procedure 'ICD-09-CM'
The combination of a procedure code and flex code definition is unique. The start date is not part of this unique key: it is not possible to have two procedure with the same code and definition, even if they are specified for different non-overlapping periods in time. The start and end data represent a condition on the usage of the procedure. For example, a claim line can only refer to a procedure if the service date is between the procedure start and end date.
Even though there can exist only a single combination of code and definition for each procedure entity, the actual attributes of the procedure that the entity represents may change over time. For this reason all attributes (with the exception of the description) are stored in a detail entity named procedure Setting. A procedure setting has the following attributes:
Field | Description |
---|---|
Procedure |
The procedure to which this setting belongs |
Age From |
Minimum age for the serviced person to which this procedure may be rendered. |
Age To |
Maximum age for the serviced person to which this procedure may be rendered. |
Gender |
This procedure may only be rendered to serviced person of this gender. |
Start Date |
The first day that this is setting is valid |
End Date |
The last day that this setting is valid. If not specified, this setting is valid indefinitely as of the specified start date. |
The start and end date on a procedure setting record are bounded by the start and end data on the procedure record. Exactly one setting must be time valid on each day between the start and end date of the procedure.
Whenever another record refers to a procedure, like a claim or claim line, this reference is always to a procedure record; not to a setting record. This makes it possible to change the attributes of a procedure over time, without breaking referential integrity or creating overhead setup maintenance.
Procedure Group
A procedure group represents a number of bundled procedures. The purpose of a procedure group is to support re-usability in the context of benefit and adjudication related setup. A procedure group has the following attributes:
Field | Description |
---|---|
Code |
The unique code for this group. |
Description |
The description for this group |
The procedure group detail keeps track of which procedure belongs to which procedure group at which period in time. Procedure group details can specify a single procedure, a fixed procedure range or a free format procedure range:
-
Single procedure. Specifying a single procedure means that that procedure is part of the procedure group.
-
Fixed procedure range. A range can be specified by specifying a start procedure and an end procedure of the same procedure definition. This means both the start and the end procedure are part of the procedure group, as well as any other procedure with the same procedure definition and a code greater than the code of start procedure and smaller than the code of the end procedure[1]
-
Free format procedure range. A free format range can be specified by the combination of a start range, an end range and a reference to a flex code definition code[1].
Field | Description |
---|---|
Procedure Group |
The procedure group to which the specified procedure belongs. |
Procedure |
The procedure that belongs to the specified group. This procedure is the start procedure of the procedure range if an end range procedure is also specified. |
End Range Procedure |
The last procedure in the procedure range that belongs to the specified group. If not specified, only the specified (start) procedure is part of the specified group. |
Start Range |
The start of the free format procedure range |
End Range |
The end of the free format procedure range |
Flex Code Definition |
The flex code definition for the free format procedure range |
Start Date |
The first day that the procedure or procedure range belongs to the procedure group. |
End Date |
The last day that the procedure or procedure range belongs to the procedure group. |
Notes:
-
The time validity of a procedure group detail must lie within the time validity of a procedure, to preclude the possibility of illogical configuration. An update of the end date of a procedure automatically leads to an update of a procedure group detail for that procedure, if, and only if, not updating would lead to violation of the business rule. The same automatic update should take place for combination check procedures, when updating the end date of a procedure.
-
The code of the "End Range Procedure" must be greater than the code of the (start) "Procedure". Otherwise, an invalid range would be specified.
-
The value of the "End Range" must be greater than the value of the "Start Range". Otherwise, an invalid range would be specified.
-
Either free format style is used within a single record or fixed style, but not a hybrid combination.
Examples
Consider the following procedure group:
Code | Description |
---|---|
R_B_PRIVATE_ROOM |
Room and Board Revenue Codes for Private Rooms (Medical/General and Deluxe) |
Procedure | End Range Procedure | Definition | Start Date | End Date |
---|---|---|---|---|
0110 - General |
REVENUE_CODES |
2012/01/01 |
||
0111 - Medical/Surgical/Gyn |
REVENUE_CODES |
2012/01/01 |
||
0112 - OB |
0119 - Other |
REVENUE_CODES |
2012/01/01 |
|
0140 - General |
0149 - Other |
REVENUE_CODES |
2012/01/01 |
The following table lists several procedures and whether or not they are considered to be 'in' the procedure group:
Procedure | Definition | Date[2] | In procedure group 'R_B_PRIVATE_ROOM' ? |
---|---|---|---|
0110 - General |
REVENUE_CODES |
2013/12/10 |
Yes, match on 1st procedure group detail. |
0112 - Medical/Surgical/Gyn |
REVENUE_CODES |
2013/12/13/ |
Yes, match on 3rd procedure group detail; start of range |
0113 - Medical/Surgical/Gyn |
REVENUE_CODES |
2013/12/10/ |
Yes, match on 3rd procedure group detail; part of range. |
0149 - Other |
REVENUE_CODES |
2013/12/10 |
Yes, match on 4th procedure group detail; end of range. |
0110 - General |
REVENUE_CODES |
2011/01/01 |
No, because of time validity. |
0112 - Medical/Surgical/Gyn |
NON_EXISTING_DEF |
2013/12/10 |
No, definition does not match. |
0120 - General |
REVENUE_CODES |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
99201 - New patient visit |
CPT_CODES |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
The following example contains ICD-10 examples as well as several theoretical examples, intended to demonstrate how the alphanumeric nature of procedure codes plays out for procedure ranges:
Procedure Group
Code | Description |
---|---|
EXAMPLE_PROC_GRP |
Procedure Group to demonstrate ICD-10 and theoretical examples |
Procedure | End Range Procedure | Definition | Start Date | End Date |
---|---|---|---|---|
0210093 |
021009W |
ICD10_PROCEDURES |
2012/01/01 |
|
02100J |
02104K |
ICD10_PROCEDURES |
2012/01/01 |
|
1 |
2 |
A_DEFINITION |
2012/01/01 |
|
X0 |
X2 |
B_DEFINITION |
2012/01/01 |
This would mean:
Procedure | Definition | Date | In procedure group 'EXAMPLE_PROC_GRP' ? |
---|---|---|---|
0210098 |
ICD10_PROCEDURES |
2013/12/10 |
Yes, match on 1st procedure group detail; part of range. |
02100A3 |
ICD10_PROCEDURES |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
021009 |
ICD10_PROCEDURES |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
02100JF |
ICD10_PROCEDURES |
2013/12/10 |
Yes, match on 2nd procedure group detail; part of range. |
02104K3 |
ICD10_PROCEDURES |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
01 |
A_DEFINITION |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
1000 |
A_DEFINITION |
2013/12/10 |
Yes, match on 3rd procedure group detail; part of group. |
2000 |
A_DEFINITION |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
X10 |
B_DEFINITION |
2013/12/10 |
Yes, match on 4th procedure group detail; part of group. |
X10.1 |
B_DEFINITION |
2013/12/10 |
Yes, match on 4th procedure group detail; part of group. |
X |
B_DEFINITION |
2013/12/10 |
No, not defined as single procedure nor part of any procedure range. |
Evaluation of a free format range instead of a fixed range works in similar vein: all procedures that have a flex code definition code as specified with a procedure code that is greater than or equal to the start range and less than or equal to the end range, evaluate to true.
Basket
Baskets are pre-configured templates that are used to authorize certain medical procedures. A basket has the following attributes:
Field | Description |
---|---|
Code |
The unique code for this basket |
Description |
The description for this basket |
Currency |
The currency for all amount fields in the basket details |
A basket has details representing time valid existences of procedures in a basket. A basket detail has the following attributes:
Field | Description |
---|---|
Procedure |
The procedure that is authorized |
Renewal Reference |
Specifies the as-of date that is used to determine which period applies for the basket detail limit. The following as-of dates can be specified:
If no renewal reference is specified, this means that the basket detail limit actually has no fixed period and therefore the counter period for such a basket detail limit doesn’t refer to a time period: it just acts as a placeholder for all consumption. |
Renewal Period |
The length of the renewal period (must be specified in combination with a renewal reference) |
Renewal Period Unit of Measure |
The unit of measure (Day, Month or Year) for the renewal period length (must be specified in combination with a renewal reference) |
Authorized Amount |
The authorized amount for the procedure |
Authorized Amount Currency |
The currency of the authorized amount; it will automatically be set to the currency that is specified on the basket |
Authorized Units |
The authorized units for the procedure |
Authorized Service Days |
The authorized service days for the procedure |
Start Date |
The start date of the basket detail |
End Date |
The end date of the basket detail |
Note that basket details have no unique key. This makes it possible to create multiple basket details for the same basket and procedure that have time overlap, for example when wanting to specify that a certain drug is authorized for 12 units per year, but with a maximum of 1 unit per month. In this scenario the Authorization Detail Matching dynamic logic function (see Dynamic Logic implementation guide for more information) should return both authorization basket details, which will result in both of them being evaluated to check if they can be consumed.