FICO Domain Issues

The FICO domain contains the details related to "coverage", including insurance policies, (governmental) programs, and eligibility.

CMETs

The main CMETs defined in the FICO D-MIM are:

• R_CoveredParty. The aim of this CMET is to convey details of a single coveredParty role, and core characteristics of the zero or one policy or program it is covered by.
• A_Coverage. The aim of this CMET is to convey the details of one or more policies or programs, including partcipations such as beneficiaries and covered parties.

Usage:

• R_CoveredParty may be used with any type of policy or program such as life insurance policy, automobile insurance, or an unemployment benefit program. When it is used in messages that have a medical focal act (e.g. medication supply), one would model the playing entity of the patient role (as participant in the medical focal act) also is the playing entity 0..* of an CoveredParty role.
• A_Coverage can be used in two circumstances:
  • An IDENT Role - what is this? may have a 0..* participation as COV with A_Coverage.
  • An Act (probably a financial act such as an account) may have an 0..* act association with A_Coverage. Note: An Act that needs to be invoiced is associated with 0..* Accounts (A_Account) acts as per the other financial domains (the act may be posted against several accounts - e.g., the patient billing account as a credit and the guarantor's bank account as a debit). A coverage act need never be associated with a focal act in non-financial domains.

(Lloyd) One use-case that's not addressed by the current A_coverage CMET is to indicate coverage in "request" mood as well as "event". I.e. When I send a prescription, I may need to indicate that the prescriber has submitted a coverage extension for the drug, but does not yet have an answer.

Multiple coverages

There are at least two ways how one could model the fact that an entity may have more than 1 coverages (or, in other words: one entity may have multiple CoveredParty roles).

1. Add some kind of grouper act to the static model that has as its components the various coverage acts, and related this grouper act 0..1 to an entity. The association between the grouper and the various coverage acts supports prioritizing the various coverages.
2. Use the ControlActProcess act (part of the ControlAct Wrapper) as the grouping act. The controlActProcess act is associated with multiple payload models, each of these payloads contains the details of one coverage. An associated constraint is that all coverages in the various payloads need to be related to one and the same entity. Currently, there is no ability to prioritize various coverages with ControlActProcess. However, (based on this use-case) IMN will consider FM's request to develop this capability.

The choice of which of these options (or perhaps both) should be developed, balloted and promoted to a standard is influenced by the relevance of the use case requirements, and whether one approach can satisfy the use cases deemed of importance to the technical committee. If there is a requirement to create a A_Coverage CMET which contains multiple coverages (this means one associates 0..1 A_Coverage CMETs with a role or act) then option 1 would seem to be the best choice. If A_Coverage contains the details of 1 coverage (in which case the grouping is done "outside" of the CMET, one associates 0..* A_Coverage CMETs with a role or act, and ensures there is a sequenceNumber in the partcipation/association)

The key issue is that coverages are NOT related to each other except for the fact that they happen to have one and the same entity which acts as a benificiary/coveredParty. This is what Michael van Campen commented about during the Phoenix meeting: the use of a grouper act would be highly "artificial". But that is only if the perspective for considering the grouping is that of the relatedness of the coverages. If the perspective is whether a particular service is covered and by what policy or program, the grouping of coverages makes more business sense. For example, the German use-case provides a reason for including a grouping act. They would like to associate a specific collection of coverages with a clinical activity. This context-sensitive approach can be modelled by assigning an ID to the grouper act (thus identifying the collection) and referencing this ID from a clinical (statement) model.

CoveredParty Interactions

A number of interactions have been proposed that use CoveredParty as a static model. In terms of static model the "Eligibility R-MIM" is essentially equal to the R_CoveredParty CMET.

CoveredParty Registry Interactions

The following interactions are send by, or send to, a registry which contains covered parties. Most of the interactions have (exactly one) RegistrationProcess as their focal act, the subject of which is the CoveredParty R-MIM.

The CoveredParty R-MIM (Eligibility R-MIM with Coveredparty Role class as its entry point) has the following identifier: FICO_RM010001 - it has 1 single derived Message Type: FICO_MT010001

Note: this is a coveredParty role registry, and not a coverage/program/insurance policy registry.

• New CoveredParty (FICO_IN010001) Notification of new CoveredParty, state change of registration of to active
  • Wrappers: MCCI_MT000100UV01, MFMI_MT700701UV01
• Add New CoveredParty Request (FICO_IN010100) Request that receiver add a new CoveredParty to the registry. This is a new registration.
  • Wrappers: MCCI_MT000100UV01, MFMI_MT700721UV01
• Add New CoveredParty Accept(FICO_IN010101) Accept of the requested registration.
  • Wrappers: MCCI_MT000300UV01, See Note (1)
• Add New CoveredParty Reject (FICO_IN010102) Reject of the requested registration.
  • Wrappers: MCCI_MT000300UV01, See Note(1)
• CoveredParty Revised (FICO_IN010002) Notification of a changed CoveredParty registration, (no state changes)
  • Wrappers: MCCI_MT000100UV01, MFMI_MT700701UV01
• Revise CoveredParty Request (FICO_IN010200) Request that receiver update an existing CoveredParty registration (no state change). **Wrappers: MCCI_MT000100UV01, MFMI_MT700721UV01
• Revise CoveredParty Accept (FICO_IN010201) Accept of the requested registration update.
  • Wrappers: MCCI_MT000300UV01, See Note (1)
• Revise CoveredParty Reject (FICO_IN010202) Reject of the requested registration update.
  • Wrappers: MCCI_MT000300UV01, See Note (1)
• Nullifiy CoveredParty (FICO_IN010003) Notification of the nullification of a CoveredParty registration (state change of the registration to null)
  • Wrappers: MCCI_MT000100UV01, MFMI_MT700701UV01
• Query for CoveredParty ID (FICO_IN010010) Query for CoveredParty IDs based on person/patient demographics
  • Wrappers: MCCI_MT000100UV01, QUQI_MT021001UV01
• CoveredParty ID Query Response (FICO_IN010011) Response - minimal: multiple CoveredParty Role classes + playing entities.
  • Wrappers: MCCI_MT000300UV01, MFMI_MT700711UV01
• Query for CoveredParty Detail (FICO_IN010020) Query for detailed CoveredParty infor based on CoveredParty ID
  • Wrappers: MCCI_MT000100UV01, QUQI_MT021001UV01
• CoveredParty Detail Query response (FICO_IN010021) Response - fullblown details of 1 coveredParty
  • Wrappers: MCCI_MT000300UV01, MFMI_MT700711UV01

Note: (1) Depends on whether we use a shared message type as a payload model [as an extract of the registration], or the full registration entry.

Non-Registry Interactions

These interactions use the Coverage/Eligibility R-MIM as their entry point.

• Query for Entity Coverage (FICO_IN010030) (parameter: coveredParty.id of one or more of the coveredParty roles played by the entity, person.id for Realms that have such an ID)
  • Wrappers: MCCI_MT000100UV01, QUQI_MT021001UV01
• EntityCoverage Response (FICO_IN010031) (response to the above query)
  • Wrappers: MCCI_MT000300UV01, QUQI_MT120001UV01
  • This interaction contains 0..* payloads, each payload representing exactly 1 coverage, there is no grouper act
• Entity Coverage Revised (FICO_IN010032) (a notification of all coverages related to a single entity, based on a user-request based trigger)
  • Wrappers: MCCI_MT000100UV01, MCAI_MT700201UV01
  • This interaction either contains 0..1 payloads (if a grouper act is added to the R-MIM), or 0..* payloads (if a grouper act isn't added to the R-MIM)