|Monday||Sep 16||AM ||Q1 9-10:30||Imperial Salon B||Plenary Session|
|Q2 11-12:30||Imperial Salon B|
| || |
Instruction on how to enter attendance in Confluence
- WEDI update
- NCVHS update
- Connectathon Updates
Discuss revisions to Attachments guidance in light of C-CDA on FHIR work
|Christol OUT. US Realm|
| Q3 Minutes:|
- Da Vinci overview for newcomers.
- Hao - asked for a project that addresses behavioral health in FHIR.
- All three PIE co-chairs may be able to attend the February 2020 meeting in Australia. Several more people raised there hands as possible attendees (Jean, Bob, Mark, Lenel, and others). If the majority of the workgroup meeting Australia, there will not be a need for an out-of-cycle location. There will be further discussion during the biweekly calls. FM WG and PIE will have joint meetings in Sydney.
Connectathon Sept 14-15:
The 22nd HL7 Connectathon was the largest yet with over 30 tracks. Six HL7 Da Vinci implementation guide tracks and over 380 participants. Also two implementation guides from the CARIN Alliance (Blue Button and Consumer-Facing Real-Time Pharmacy Benefit Check). The CARIN Blue Button IG Track had about 20 participants, set up 7 servers with data, and 11 client apps were able to connect to servers and pull data. The RTPBC Track had 4 participants who tested the FHIR API implementation approach and were able to successfully connect to PBM/payer data, display benefit information, and cash price to the consumer. The purpose of the Connectathon is to enable consistent testing of HL7 FHIR IG with the use of FHIR Resources and API to ensure it is implementable in the real-world. BCBSA and BCBS Plans including Anthem, Cambia Health Solutions, HCSC, BCBS AL, and BCBS TN participated.
CareEvolution and Brandon Raab represented Anthem at the HL7 Connectathon. This satisfied Anthem’s pledged commitments from the 2019 White House Blue Button Developers Conference. The Da Vinci use cases and FHIR standards also continued development during this conference.
Blue Button 2.0 from CMS is an API that contains four years of Medicare Part A, B and D data for 53 million Medicare beneficiaries. This data reveals a variety of information about a beneficiary’s health, including type of Medicare coverage, drug prescriptions, primary care treatment and cost. Beneficiaries also have full control over how their data can be used and by whom, with identity and authorization controlled by MyMedicare.gov.
Blue Button 2.0 uses the HL7 FHIR standard for beneficiary data and the OAuth 2.0 standard for beneficiary authorization.
CDex Track PPIE HCSA, Accenture, BCBSAL, Anthem, Deliotte, Availity, HSPC, Diameter Health, Tibco, MaxMD, other drop-in’s
Deloitte – Russ Ott, Chris Brancato
Availity – Henry Meyne, Kyle Zumstein
Anthem – Christol Green
Blue Cross Blue Shield AL – Kevin Lambert, Clarissa Winchester, Morrey Payne
Accenture – Ozair Bajwa
Discussions with Mitre, Humana
BCBSA – Lenel James
Diameter Health – Karen Zapatta and John
BCBSTN – Heather Kennedy
Humana – Patrick Murta
HSPC – Jason
Throughout the connectathon we worked with the HSPC (Logica) Sandbox to populate data and test the CDex use cases, as well as refining the capabilities of the sandbox to better support support CDex use cases. Submitted requests for documentation using the CommunicationRequest resource, and responded with Communication resources including CCDA payloads and references to the corresponding CommunicationRequest.
Also BCBSAL and Diameter Health worked on CDex from AL to Diameter FHIR sandbox.
A key outstanding challenge is the need to figure out how patient discovery and identity will be communicated reliably in these transactions. Generally payers work with a Subscriber ID at the family level, and require First Name, Last Name, and DOB to identify a unique patient. Should a patient discovery query occur first?
Our next steps are to continue testing with a focus on patterns for identifying patients.
FM joining PIE
- FHIR Da Vinci new ballots discussions /overview
|FM,Bob and Viet|
|Q4 Minutes: |
Reviewed FM agenda and revised joint meetings with PIE. FHIR Da Vinci new ballot discussions /overview - Bob went over CMS NPRM Information Exchanges supported by Da Vinci IGs. Not going to ballot since it has to do with alerts. Kieth asked if advancing standards will be in line with any new regulation in December. Not likely to be referenced in a final rule. The rule will state a need, and Da Vinci will have it built. The goal is to ensure one standard for implementaion. Da Vinci will clarify that goal to provider/payer community. Alerts and notifications are not the same as an ADT. A notification example is that a hospital lets provider or payer know that a patient has been admitted to a hospital. An alert may need an action to take place. Future FHIR enabled solution. FHIR Prior Authorization Endpoint Interactions. Rachel asked if there is a project or standard for the cards in CDS Hooks. Errors are not defined, but come from the base standard. Business concerns regarding when they will receive a response. Availity checks every hour for responses from payers, then sends to provider. Bob showed a summary of Da VInci ballot comment volume. DOD, VA, Kaiser and Quest had the most negative ballot comments. Should have a block vote ready next week to address 80% of comments. It was noted that the guides were not reviewed closely by co-sponser of the project based on the number of typographical type errors.
|Tuesday||Sep 17||AM||Q1 9-10:30||M105|
- LOINC Review with Regenstrief
|Dan and Swapna|
New LOINC: 1. Itemized Bill 2. Medical Record for Authorization Denial (52032-0)
| Q1 Minutes: |
- Reminder to log into Confluence to add attendance
- Co-Chair meeting summary, see document.
- LOINC Review with Regenstrief - LOINCS for the HIPAA tab were added to"Valid attachment requests" and "Documents without IMP guides" tabs. See list of LOINC codes added. Lisa Nelson asked if these are for unstructured document requests. These codes are not in the C-CDA guides. Dan stated that C-CDA has a superset of LOINC codes for structured documents. FHIR value sets. Twice a year refresh LOINC downloads. VSAC can be sent in CDA as unstructured body. CDA points to what regenstrief puts out there. CDA pulls by value set definitions. General codes and sets of codes under "documents with implementation guide" tab have value sets. Sam asked what successful process to use when charting from EHR to a generic LOINC code. Danielle from Epic stated that a given note type encoded within the EHR system and are working with vendors. US Core guide. It is not automated when someone maunually has to pull the best/correct document that the payer has requested. All text may not have a code. Offices/vendors should at least have the basic general codes, which the vendors most likely will . The Value Set Authority Center (VSAC) is for management and distribution of codes. Information is the same whether using C-CDA or FHIR. Redefining the same value sets for FHIR. Can download value sets based on and OID, for example, history and physical. Download value set spreadsheet, filter on all LOINCs for H&P. C-CDA should be refreshing VSAC twice a year. Go to www.HL7.org under master grid, look up C-CDA. There is a single product page with all the versions and value set release packages (06/28/19 was last update). The vision is for a value set expansion registry to automate request and receive. Regenstrief is used to do that and is the source for all LOINCs. C-CDA companion guide. USCDI v1 since it is brand new, so no value set ready yet. There should be a URI for lab report narrative, for example. The level of USCI is not the same. ONC should be more precise as what the value sets should be for listed USCDI list. CDA is constrained compared to FHIR. FHIR is a more flexible granular environment. Vital signs contain blood pressure, but was blood pressure taken at rest or after a 6 minute treadmill walk? Concepts and level of definition changed with USCDI. When the information is the same, then there should be only one value set for information that is the same. V2 value sets are pullled forward in FHIR. There are concept differences in V2 vs FHIR, such as Encounter types. There needs to be interdependence between workgroups. Payers need to be using the same codes as providers and EHRs. To summarize, for structured documents the list is exactly the same. It is the unstructured documents that are not. There is no unstructered list in VSAC. There is an OID for all possible unstructured value sets in Regenstrief based on the attachments implementation guide link. Attachments has a process that expands codes in Regenstrief. As a resolution, Lisa said this will be added to CDA guide and to VSAC and update twice a year. How does a payer ask for weight? The Imp guides may have lists or mappings. CDA results in an EHR (EPIC) LOINC from lab results may have a default value. Does payer asked for vital signs or lab result? Vital signs would have weight. Could add instruction in guides. CDA mostly provides a document whereas FHIR can be more specific. The EHR vendor must map because it dictates what the provider can do. EPIC - depends on how everything is mapped or tailored to a client. Maybe start with a CORE set that all vendors know of and get from the implementation guides. US CORE provides the granuality. CDA or FHIR paridigms are what are supported by EHR vendors. May need to define a new use case for EHR vendor. Providers use what is available today, such as documents.
- Anthem asked PIE for two new LOINC requests. No LOINC for itemized bill and medical record for authorization denial. 52032-0 is to appeal a denial, but is not a prior auth denial. Send to Regenstrief to research appeals of the prior auth denial and medical records for an auth denial. What is the workflow when claim is denied? Anthem will use the formal request through Regenstrief.
- Further discussion and coordination between EHRs, FHIR, Regenstrief, and Payers. Are requests at the element level, data level, or resource level for FHIR. The transition to specific data in regard to just docucments as in CDex track for specific data.
- 824 Acknowledgements
- US Realm Update
- Ballot overview
|Russ OUT - Structured Docs|
|Q2 Minutes: |
- Summarized discussion in Q1 . Mostly an EHR issue and should be included in an accelerator projects Profiles do not have use cases tied to them. Continued the discussion. There is overlap, see Da Vinci CDex. What will be the process for requesting a new profile?
- 824 Acknowledgements - For WEDI, Mike explained the education perspective. Define how X12 acknowledgements work. CORE rules gives some guidance on when to use transactions. Basic 101 information regarding acknowlegements. The healthcare industry and mortgage companies use 824 differently. When to use 824 in healthcare? When the 275 HL7 fails? Scope out the business need, best at front end/gateway. The 824 acknowledgement to a 275. Mary Lynn is working on list of error codes that should be added to the 824 to address HL7 data received in the 275. 3 elements in the BDS (6020?), 8 codes, BGN says if unsolicited or solicited. CAT segment, then binary segment Is Mary Lynn's list enough? The question is ECO code, but too late to add to 7030. Send to maintenance group 2 in X12, since no one currently sends HL7 with claims, not sure about what errors are needed. This workgroup may need to think of any HL7 needs in the 824 that can be given to X12 as they work on thee 824. The EHR systems do not currently support the 824 transactions. FHIR may be able to go forward with error codes before the X12 824 guide comes out. The code set itself could be developed without waiting for 8020 X12 version. Rachel motions, Susan seconded that Mary Lynn should move forward with her codes. Vote on her to move forward. Bob - the attachments guide says to respond with what you have, so the error LOINC code does not match the LOINC code in the request. Recommend that should be taken off the list because it does not meet instructions in the guide. Recommended to look at the language "document does not meet the request" is not specific. TASK - talk to Mary Lynn regarding the changes. RFC requirement codes may need to be omitted. Review that with Mary Lynn.
- US Realm Update - see notes. Also summarized in the meeting this morning.
US Realm Discussion: GOM Section on the US Realm Steering Committee
- Discussion regarding how US Realm would monitor US Realm projects after approval. General agreement that it would be useful. Could add checkpoints on whether content is ready to go to ballot, ready to be published. Could have a policy that a WG develops a checklist of US Realm requirements that they need to complete before going to ballot and final publication. WGs are going to start submitting quality checklists at ballot and publication so perhaps they submit a US Realm checklist at the same time. Could have additional information added to PSS to provide monitor points.
- This would be a product line management activity vs. the product family management aspect that we currently engage in.
- Need to know US Realm projects in flight - could be pulled from Project Insight.
- Quality checklists will start being required a year from now.
- Idea that when you click US Realm on the PSS form, a checklist of requirements pops up
- Develop US Realm Quality Checklist
- Consider how to update the PSS to include a link to checklist
- Discussion over how to advise HL7 US stakeholders on how best to engage with HL7 and what that looks like in terms of government agencies, new accelerator programs, and vendors/industry associations. Could invite new accelerators or groups developing US artifacts to come to US Realm before they start developing.
- Discussion over how to go about supporting the development of baseline US vocabulary and terminology requirements. Perhaps should be less broad to say "encourage the adoption" of baseline US vocabulary.
- US FHIR extensions development and sharing: would handle promotion process to US Core and FHIR Core
- Do we set priorities for US HL7 standards development? Discussed pros and cons and how to determine the priorities
Nominees confirmed by TSC to fill ad hoc and at large US Realm positions:
Christol Green (Payer)
Chris Shawn (Security/Privacy)
Danielle Friend (Implementer EPIC)
Jenni Syed (Implementer)
Rob McClure (Vocabulary)It may add value to have a checklist in the process for ballot comments and PSS for US realm only. Get involved before PSS is written. Where is US realm in confluence? Next call topics.
- Bob provided status on Da Vinci projects that went back for ballot (CRD, DQM, DTR) ballot. Status of other projects can be found in Confluence, for number of comments and where they are. Will get block votes ready for some comments and will be addressed on calls by end of November. Should become STUs. Following process so two will be ready for publishing.
|PM||Q3 1:45- 3||M106 & M107|
FM joining PIE
Prior Authorization Support Ballot Reconciliation
|217 comments ||Russ OUT - Structured Docs|
| Q3 Minutes:|
Da Vinci ballot comments submitted by Keith Boone to go over in person.
- #24166 - In the Introduction, Practice management solutions and revenue cycle management may be responsible for prior auth and must integrate with EHR systems. Instead of stating that EHR systems cannot support it. Sentence will be modified. Few have this interface out of the EHR going to the payer. VOTE: 29-0-3
- # 24169 - Why claim extension for an institutional encounter? There is an encounter resource in FHIR that represents patient interaction. One claim can have mutliple encounters such as lab work, X-ray, physician visit, etc. The extension provides encounter data at the header level. It is already done at the detail level (lines/prodecedure codes). An encounter at the resource level. Track 2 items: 1) Make a core extension to add the encounter at the header (R5). Change the IG if a global extension referencing the encounter and becomes available. Not specific to claims, but can be used in claims and EOBs. 2) FM will research episode of care extension. VOTE: 29-0-4 abstained.
- #24171 - extension on an item to say an item has been changed or added. This needs research as far as mapping and vocabulary. Needs follow-up by FM workgroup.
|Q4 3:30 -5||M106 & M107|
Joint w/ EHR, CIMI
| Q4 Minutes:|
- Joint w/ EHR - CIMI and PIE in attendance - podiatry functional profile and wound assessment. Podiatry Profile Project with Michael Brody. Components include wound template, vascular evaluation, consent. See document in EHR on confluence. FHIR Skin Wound Assessment imp guide STU1 developed use cases. Talked about photos that come from a tissue analytics machine. Working on a virtual connectathon. Create conformance criteria. Reed added that the template leverages authentication attributes. Ability to capture the source of information. All clinical information will be "null", the only author is the provider. Validity in FHIR implementation guide with authenticity. See draft EHR podiatry functinal profile use case scenario worksheet in confluence.
- Discussed other EHR projects such as EHR system functional model and version release. Take an Excel spreadsheet, run it through the tool to export as Excel, PDF or HTML. Nutritional functional profile got no comments. EHR implementers are reviewing. Focus on new material and changes.
- Dental profile with Greg Zeller.
|5:30 - 7:30||PARTY||Da Vinci - Party at Max Lager's|
|Wednesday||Sep 18||AM||Q1 9-10:30||M105||Greg |
| Q1 Minutes:|
- Went over agenda for the day. Tony had to leave so PDEX was taken off of the agenda.
- Reminder to fill out attendance on Confluence.
- Dental Discussions - see slide presentation. BCBSAL is going to implement the dental attachments using the guides. Government programs are prompting interoperability because of the importance of dental readiness of military personel. Timeline for STU in C-CDA. CDA will work better than FHIR for now. CCD will work with currrent systems. Piggyback on CCD which is already there and adopt it for dental. Start thinking about getting dental into FHIR R5 which is about 3 years out and keep from waiting for R6. Working on PSS. Will work with EHR vendors for early testing. See project links in Confluence. The Korean delegation is interested in exchanging internationally. May be able to piggyback on their terminology. Attachmetns is the sponsor. see confluence project. The CCD imp guide supports the dental use case and is in wide use already. Dental summary exchange program on project summary page with 1084 to CDA constructs and statement of understanding at ADA. Functional profile points to HL7 CCD. Pivot table has mappings, with 40 to 50% already in CCD to reuse in dental. Odontogram used currently instead. Vocab already done for the odontagram. Need approval from the work group for the PSS. Get scope statement approval from the workgroup. Will add cosponsers. Dental summary exchange PSS section 6f stakeholders, added other stakeholders that were not listed. Dental providers, patients, clearinghouses, federal health sector, institutions, registries and schools. In section 6g, add other vendors such as electronic dental record vendors and dental labs. For section 6h, add other providers, federal health sector providers. Change project name to "Dental CCD Implementation Guide PSS". TASK: talk to Josh about updates and editting. Suggested that EHR and patient care workgroups would be co-sponsors or interested parties. Bob suggested CDA so fhir will be in the future. The eventual intent is to develop a corresponding FHIR IG to convey the same dental data. Update section 2c, when co-sponsors are found. Added to section 2m for implementors actual vendors. Went over the PSS, made revisions real time. Consult with structured docs about C-CDA template for future developement. Jean motioned to approve, Laurie as second, no further discussion. VOTE: 17-0-0, approved. Will get the PSS on the agenda for US Realm to approve on their call next Tuesday. Can track it as it moves through the approval process. Will go over PSS on the next workgroup meeting call.
- Status of combined periodontal and ortho guides since periodontal STU is about to expire. Needs to be addressed. Reaffirm the standard for perio. What is the process for that? Could broaden the scope to include the perio/ortho attachments. Discuss as a take away on the next call to discuss combining the two attachments.
Dr. Michael Brody
|Russ Ott - Security|
|Q2 Minutes: |
- FM joint review of IG material. Coverage profiles (Hrex, PAS, ,US Core coverage profile) , Claim profile. Review the coverage profile because of confusion. Need clarification or addtional documentation. Talk about design, multiple covergage. data elements in resources. Da vonci has two different profiles and discuss why there are two. do we need thee two? Q1 thursday will go over data elements. Paul - qiuick review. RESOURCE CONTENT. Coverage resorce is could have multiple plans. i plan with 3 coverages or 3 coverages under 1 plan. therem is also the case of self-pay.card level identification. it does not include coverage. plan identofier can be common in the coverage resource. also under contract element. see structure slide that starts with member#. family coverage each patient has a separate profile. it does not specify primary, secondary, tertiary. type captures if workman comp, auto, health. subrogation also allows. there are other resources that defines the coverage policy. from this resource conduct a query to the plan resource. discussion of the terminiogy and business needs in the resources are not as familiar inthe US. use common components.the coverge resource by it self must have other resorces based in the order of multiple insurances. the weak link between "coverage" and "insurance plan". r4 an extension can be used. what are the common identifiers familiar to provider and payer in order to exchange the information. find under da vinci profiles on coverage. snapshot table. prior aothorization support coverage profiles. one profile for subscribers and one for the beneficary. so the prior auth profile should have all elements of the 278 x12 transaction. ATREX has the other coverage profile (da vinci) is at a higher level. atrex candidate for us core. as far as cardinaelity is concerned. the payer assigns member numbers, so there is no way to tie those into. The payer element tells you thw format of the memeber id. how would it look in the porilfe with examples. cannot resolve the confusion, but examples of use cases can have the examples Q1 thursday?? what is missing in the coverage rewsource??? need examples such as assigning aiuthority element.
- Discuss Wound Care reimbursement data requirements - template. michael brody - podiatry profile project. not able to exchange information with other providers regarding wound care. Developing an IG modeled on the medicare LCDs. there is an IG uo for ballot for wound care assestment cimi involved in . anthem states that you have to go on acvaility we site to fill out data oppoints for the ckliam to pay. WHat are all the dat points required for the treatment for wounds. Asking payers to provide this for the IG. da vinci clinical decions should review this because it is for prior authorization. PPIE as a group who collected oit, how was it collected, etcwere questions from anthem. EHRs have been exempt from the federal laws and rules. the wound car template would require an authenticated, authors, data quality. capture information from the EHR as part of data qualituy specification. prior auth for wound care. data points needed by medicare (LCDs) and empire bcbs. have they captured all the data points, asking other payers???? da vinci could look into having encoded as to sign, digital signatures, provenance. data points coming from the 278, but there are things that can integrate this into a workflow. da vinci pilot prgram. it is a scenario for prior auth under da vinci.. bob worked on surgical dressings, so he will look into wound care added as a use case/senario in da vinci.
|PM||Q3 1:45- 3||M101||Review Attachment download documents for updates (PIE, formally Attachments, other industry versions etc.)|
|Q3 Minutes: ||Volunteers are needed to review documents. Check links to make sure they are working. References to AWG or attachments workgroup should be changed to PIE. Documents dated Aug 2017 STUs have expired as of Aug 2019. Need a QA checklist of changes that need to be made in each document. Links to sections and adendums within the document not working. References to WEDI website and HL7 website. Are tradmarks correct? When some Word documents were converted to PDF, some of the links no longer worked. Who has the original word documents? (Laurie Burkhardt, Durwin Day, Debbie Misner). ACTION: find original documents. Did the June 2019 C-CDA document replace Aug 2017? The word documents are available in the HL7 attachments workgroup page and may not have converted in confluence as PDF documents. *CDP1 - bob may have the original. the zipped file has aug 2015. is copyright in footer correct (2015)??? references to attachment workgroup. no references to AWG. DTSTU is now STU. stopped using the word draft. Use standard for trial use. there are references to ICD-9. * periodontal attachments - dated july 2017. references to attachments workgroup. DSTU references. |
- HL7 Consolidated CDA R2.1 (C-CDA R2)
Page 1 Child Health work Group (Capitalize “W”) both Vol 1 and 2
- HL7 CDA@R2 Attachments Imp Guide: Exchange of C-CDA Base Doc Release 1
- August 2017 expired? DSTU to STU
- Title page not (Universal Realm)
- Change AWG to PIE throughout document (starts at 2.5)
- What is Attachment Conformance requirements (pg 8)
- Page 9 underlined references do not link
- LOINC Registered page 11 logo
- CDP1 –
- Sept 2017 date of expiration? DSTU to STU
- Replace Attachments WG with PIE throughout document
- Periodontal Attachment
- July 2017 expired?
- Attachment Work Group to PIE
|Q4 3:30 -5||M105|
FM joining PIE and FHIR-I
|Q4 Minutes: ||The intention was to raise the issues from the processes elevating extentions. Paul will bring up the issues in an upcoming meeting. FHIR infrastructure. See claims and reimbursement. Accounts and billing. Hl7 is healthcare specific, but not specific to accounts receivable which are FM areas. Cerner was involved to increase scope in invoicing and payments. The current resource payment reconciliation resource may not be accomadated. cerner has done some work See presentation"interioperability for patient payments"on-line bill payment workflow. there is an "account" resource, but balance is not an element. cooper from epic created tracker numbers. ray was on the phone and put it together. notes are under tab called documentation in the finanxcial mangement page. patinet payments and fjhir v2. brian - www.developers.instamed.com/ go to consumer e-statement presentment, scsumer billing ,opoup window. gaurantoer, id , patinet account#, etc. high level summary, totl balance amount due. othere cases have encounter based billing that does not inclusde previuous payments on an account. payment methods and pat-to address. went over a stemet data elements. would we support updates to demopgraphics? the patient resource could be used to upodate demographics. shoiuld it be put into the stement resource??? practicwe maneagement systems do not allow for changeing demographics. aging bnuckets 30 60 90 days. past due . go back to browser/consumer paymentss/ payment posting/posting file formats on left hand side. example is webhook (default) master format?examples. view in json, xml. there are a lot of fields in the . multiple file formats because ofmthe diffierent practivce management systems. the practice management system renders elements as a staetement. this format handles sevearl use cases. payment method/format. the estimator can be used for a pre service sending amount paid against the estimate in workflow system. estimates are becoming more and more common in the future. such has high deductibles and hiospital wants to collect payment upfront is an example of a use case. CMS NOPRM regarding price transparence, da vinci is developeing cost transparency. confer with OCR released something in regard to this. click on Payment PLans - if a patient have a large balance, they can set up a paymernt plamn ib tbe practivce management system. use case of payment plans to make sure balance does nothave to be paid in full. patient must agree with the payment plamn. payment may be made automatically against credit card, etc. provider can cjhoose to offer payment plan, minimum amount, duration, etc. most practice management systems to not provide payment plans, so thaey get an extgernal company like instamed. WHAT IS THE NEXT STEP???? paul suggests 1. a separate call to deal with this topic because it is needed but is a grat deal of work. instamed is interested and provideing use cases, use cases, etc. cerner list other vendors, exoerian, etc about 7 competitors. appropriate resources to work on it. cernrer has resources to help. aleready talking to others in the industry. take ir offline as to acailbilty of co-chairs. how do we staff it to be involve din the calls. instamed works with cerner and epic. they asloso have a variety of provider specialties to join the call. same as project with anesthesia workgroup. long term care has different criteria. needs standards applied to the billinfg aspect. mary kay asked cerner (on the phone)for a project manager. ehrs use this foor their revenue cycle. ** projects deal with v2 to fhir conversions. mapping, tooling. in1 in2 ft segments segments. has to come through orders and observations in confluence doing their oru, lab. they are sponsoring because thaey started it. mapping under fm . maps between v2 data types and fhir datatypes. |
|Thursday||Sep 19||AM||Q1 9-10:30||M105||FM joining PIE|
|Q1 Minutes: ||Gforge/HL7/FHIR/Tracker ID 24638, browse. Followups submitted on Wed sept 18. Vassil Peytchev. The coverage.subscriberId is a business identifier, used in business processes to reference real world entities - see FHIR specification: "[...]systems SHOULD: * 3 bullets. Subscriber ID is a label, then a string. Propose to change datatype from string to an identifier (may have use, type, system, etc.) Should we change the datatype? At the bottom of previous Gforge page...Subscriber ID is currently a "string". As an example, Medicare issued new IDs after April 2019, but same coverage. Can use both old and new identifiers for a grace period based on date of service. Bob stated that if the cardinality changes it may be a solution. The purpose is to create a new coverage record. For claims, the ID used is based on date of service. This is more of an administrative need to be used, member ID is already an identifier, so no problem. Using system to validate the format of the old and new IDs would have the option to have the assigning authority if needed. EPIC and Cerner already has a need for this. The real Question is why this is an issue? It is a codeable concept use instructions to profile out and give guidance with codeable concept can be done today in R4. profile out the two strings. group did not agree, but that changing subscriber ID should be changed to identifier. Rachel motion to change from string to an identifier in R5. Kathy Pikering seconded. Terry abstains. 19-0-2. See all comments in tracker. See tracker item# note at the bottom related to thi coverage.dependent is also a string. next tracker item# Reword from "unique identifier for a dependent under the coverage" to "Within the coverage, a way to separate or identify the dependent. In some jurisdictins this may be "01" or "AA". A subscriber may have a dependent number". move to table this and work on the new description on a call. unanomus vote Christopher Schaut. New Tracker #24641 - update coverage.class.type definition. Insurance plan resource, go back and model this. Patient admisistration, HL7 FHIR resource types, medical, insurance plan (draft). For business needs, exchanging identifying information of a plan needs work. akin to x12 270 eligibility/benefit requests maybe not used for claims. in the registration system business need to link information. In FHIR, there is an issue in the coverage resource class identifiers. Example: federal market place NAIC number has marketcoverage, delta dental has several plan products under |
|Q2 11-12:30||M105||Clean up new PIE WG Confluence site|
|Q2 minutes: |
- Clean up new PIE WG Confluence site and hl7.org page - mission and charter was updated, but HL7 site has old mission and charter statements just with the workgroup name change, not the new revised document. Christol sent document to Josh. Also on the HL7 site, there are ballot cycle/guides may have expired. submit documents with revisions as substantive or non substantive changes may not be substantive if adding links to FHIR. No references to FHIR, so may be substantive. HL7 site changes were made by Josh. space tools/reorder pages . Use drop down menu under payer/provider information exchange home. Drag agendas and minutes into 2019 folder. adjust macro under 2018 and 2019 folders added under conference call meetings. copy agenda and it save it where change to minutes. can do the same with workgroup agenda.
- Imp guide states that FHIR is a merging standard. also universal realm. table for call meeting to discuss/address. back on the hl7 page cleanup titles and sections. work charters and contributions under CHARTER. Title was there twice. the PSS template still has attachments, change to new name. Josh can make some changes to the confluence home page that will take time to refresh.
- Regarding making changes to documents. publication request and sdo or errata or extensions
- Regarding documents that were not converted correctly from word to PDF. if we fix the links and make changes to the document, can use formal process errata publication request. the read me file. update pss macro will take some time. Josh will check into the errata reposting documents.
- Look at documents that have links that no longer work. Different versions of Word may cause PDF document to format incorrectly. For HL7 reference materials, are some of these really suppose to be links? Originally, hot links were throughout a lot of documents, such as CDAR2 AIG. ACTION: Find the original word documents or revise in adobe for PDF. Resaving as a PDF may correct some issues.