Motion to approve. MaryKay McDaniel / Jeff Brown 5-0-0
R5 - need to reword the roadmap section
currently:
13.0.17Developmental Roadmap
The Financial Management Work Group (FM) is responsible for two subdomains:
Financial Accounts and Billing (FIAB) - resources for accounts, charges (internal costing transactions) and patient billing, and Financial Claims and Reimbursement (FICR) - insurance information, enrollment, eligibility, predetermination, preauthorization, claims, patient reporting and payments.
To date FM has been focusing on the resources required to support the exchange of claims and related information between health care providers and insurers. The first draft of this work is nearing completion with the release of the first Financial Standard for Trial Use in STU4 of FHIR. Over the next year further refinements will be expected as implementers begin developing regional profiles and begin live pilots with resources.
Once the above is well underway FM can then look to developing the Enrollment-related resources and the resources to support the FIAB functions.
3/21/2023 - change to:
FM has been focusing for R5 on the resources required to support the exchange of claims and related information between health care providers and insurers and the payment-related resources (PaymentNotice and PaymentReconciliation). Further effort is required to correct and mature the terminologies used in the financial resources.
Additionally FM can consider developing the Enrollment-related resources and the resources to support the FIAB functions.
2/28/2023. Technical error. will deal with it in QA
14-Mar-23
R5 targetted tickets did not all get applied
We are pulling out what didn't happen
Q: Are resources at FMM 0 going to move forward?
A: (PK) Removed from the pub kept in cont build
Q: Part of PMM3 is talking about number of tickets, is that a hard requirment?
Review of FM owned R5 resources to determine if we need/want to change their ranking in the FMM
Account
Question for Paul for FMG: Account is heavily used, we would like to move to FMM3, but without 10 distinct comments we don't meet the requirement. Do we really need more comments or can the known heavy use still allow us to move forward?
We had 1 big ticket that could have been broken into several comments.
Contract
We have outstanding changes, that simply weren't applied
Coverage
MK thinks Coverage can move up to 3, no disagreements
See FHIR-33202. Another ADA code system (tooth identifying system). Add to THO
Jeff reaching out to Rick for an update.
Paul - we can do a better job for example codesets, especially in places where each country may have their own codeset. (IE Billing codes) where the codesets can vary widely.
We are working on value sets in improving definitions for interoperability. Targetting R6 for that cleanup.
VOCABULARY UPDATES: Coverage.type
Steps:
Review each resource (alphabetically)
Identify each vocabulary that needs to be updated
Replacing the v3 ActCoverageTypeCode Value Set
***We have SEVERAL R5 tickets around this value set: 13024, 14127, 24916, 20361 (these are linked and in FMWG-Discussion Grouping)
VOCABULARY: General
Resource
Element Path
Change Required
Discussion
Coverage
.type
Currently CodeableConcept/Preferred with a bag of codes. Committee is reviewing whether to replace the bag with a more structured series of codes.
.status
none
.kind
none
.relationship
none
Currently CodeableConcept/Extensible with a THO registered internationally applicable codes and a FHIR valueset.
.class.type
none
Currently CodeableConcept/Extensible with a THO registered internationally applicable codes and a FHIR valueset.
.costToBeneficiary.type
none
Currently CodeableConcept/Extensible with a THO registered internationally applicable codes and a FHIR valueset.
.costToBeneficiary.type
discuss whether we can define a base set of codes then either do so or create new example codes
Current example code may not have appropriate rights to use.
.costToBeneficiary.network
2nd Review of codes
Currently CodeableConcept/Example with a THO registered internationally applicable codes and a FHIR valueset.
Suggest binding=Extensible after second review of the codes.
1st review of codes on 2022-11-01
.costToBeneficiary.unit
2nd Review of codes
Currently CodeableConcept/Example with a THO registered internationally applicable codes and a FHIR valueset.
Suggest binding=Extensible after second review of the codes.
1st review of codes on 2022-11-01
.costToBeneficiary.term
2nd Review of codes
Currently CodeableConcept/Example with a THO registered internationally applicable codes and a FHIR valueset.
Suggest binding=Extensible after second review of the codes.
1st review of codes on 2022-11-01
.costToBeneficiary.exception.type
2nd Review of codes
Currently CodeableConcept/Example with a THO registered internationally applicable codes and a FHIR valueset.
Suggest binding=Extensible after second review of the codes.
1st review of codes on 2022-11-01
CoverageEligibilityRequest
.priority
needs motion
Keep the definition consistent across FM resources (Claim, ClaimResponse, EOB)
Currently CodeableConcept/Example with a THO registered internationally applicable codes and a FHIR valueset.
Suggest binding=Extensible after second review of the codes.
.purpose
11/8/2022
needs motion
Currently a code datatype and therefore a required binding.
Suggest changing the data type to CodeableConcept (Extensible) using the current codesystem and valueset.
.item.category
needs work
Replace the existing example codes with a shorted, alphanumeric list of codes so that there is no confusion that these are someone's Service Type Codes or that the list is complete.
.item.productOrService
needs work
Example codes need attribution or to be replaced with a different example set,.
.item.modifier
Consider renaming the codesystem and valueset to 'ex-'.
.item.diagnosisCodeableConcept
none
CoverageEligibilityResponse
.status
none
.purpose
11/8/2022
needs motion
Currently a code datatype and therefore a required binding.
Suggest changing the data type to CodeableConcept (Extensible) using the current codesystem and valueset.
.outcome
none
Currently a code datatype and therefore a required binding.
.item.category
needs work
Replace the existing example codes with a shorted, alphanumeric list of codes so that there is no confusion that these are someone's Service Type Codes or that the list is complete.
.item.productOrService
needs work
Example codes need attribution or to be replaced with a different example set,.
.item.modifier
Consider renaming the codesystem and valueset to 'ex-'.
Category: Payer Initiated Reductions / Reason: Performance program proficiency requirements not met / Amount
01-Nov-22: The US has unique requirements. There's a desire to see how we can synchronize international code usage, as much as possible.
There are also situations where different jurisdictions have elements with the same name, but different meaninging.
supportingInfo Slices in existing IGs:
CARINBB:
Billingnetworkcontractingstatus
admissionperiod
clmrecvdate
typeofbill
pointoforigin
admtype
discharge-status
drg
medicalrecordnumber
patientaccountnumber
benefitpaymentstatus
dayssupply
dawcode
refillNum
refillsAuthorized
brandgenericindicator
rxoriginCode
compoundcode
performingnetworkcontractingstatus
servicefacility
PAS:
PatientEvent
AdmissionDates
DischargeDates
AdditionalInformation
MessageText
InstitutionalEncounter (information about a hospital claim being requested)
VA:
Initial Placement (dental claim)
Do we need to add any of these to the base?
01-Nov-22: We might add to base is to guide IG authors in the best practice for adding this data.
CARIN made the design desicion to NOT use any extensions, and so they are using supportingInfo slices. Other IGs are using extensions for the same data elements. We'd like to simplify this for implementers with a standard.
The HL7 Antitrust Policy was approved as part of the last GOM Revision
Section 05 Antitrust Compliance
The following statement must be added to the minutes for each meeting:
Professional Associations, such as HL7, which brihng together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust lawas were enacted to promote fairness in completion and, as such, supports laws agains monoploy and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in 05.01 of the Governance and Operations Manual (GOM).
HL7 is a community where we can always ask searching questions about technical matters and how our decisions might impact our various communities and stakeholders, but HL7 and its participants are committed to a harassment-free environment for everyone, regardless of level of experience, professional background, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Generally this should mean there is no reason for those subjects to come up with regard to any specific individual.
Co-chairs are asking our WG participants periodically review the HL7 Code of Conduct .
Started a new confluence page to list all ballot reconciliation resources. If anyone has any that are not listed there, please update and let the rest of us know!!!
The HL7 version naming convention is: v.b.r v =published version number. Pre-publication v = 0, STU1 = 1, etc. b = ballot number for this version. balloted 1 time b = 1, etc. r = revision number. The IG team can use this as they wish.
ID vs. IDENTIFIER: ID- Local to the resource creator, IDENTIFIER- an identifier everyone recognizes. Independent of where the information is created or by whom
