HL7 Attachments Workgroup (ASIG) Minutes (Draft)
April 14 – 16, 2009 LasVegas, NV
ASIG Co-Chairs
1. Rob Root, PGBA2. Durwin Day, BC/BS Illinois
3. Jim McKinley, BC/BS Alabama /
Attendees
· See file: ASIG 2009-04 LasVegas Sign-in Sheets Final.xls, and (if reading these minutes as a PDF, the final page below)The ZIP file containing the referenced presentations and other documents are available on the “Meeting Minutes” section of the www.hl7.org/asig web page.
Note 1: The end of this document contains a quick summary of motions, presentation file names, and new action items.
Tuesday (April 13) – Q1
Agenda Review
The week will be comprised of Review of booklets for the Final Rule: Rehabilitation, LOINC Modifiers, Clinical Reports, Ambulance, Medications, Laboratory Results, and Implementation Guide. With the exception of a couple items, this will be the ASIGs primary focus in Las Vegas.
Rob projected the document: “Booklet editing for Las Vegas”.
Kepa is coming in Wednesday and may be able to assist us with the X-path statements: syntax, OIDs, etc. Tamara reviewed the Medications and completed the review of the OIDs. She may be able to assist with the validation of the OIDS in the other guides.
Jim & Rob believe the technical items are in jeopardy of not being completed by the end of this work session since we do not have any technical SME attending. The ASIG will focus on the editing and complete that area. No matter how thorough we feel we have been with editing the booklets, publication will prompt additional questions and issues.
Let’s go back to the documents we have. Everyone needs to review their documents using the ‘Booklet editing for Las Vegas’ list
1. Implementation Guide: haven’t heard back from Mike Cassidy. May review one last time and let it fly.
2. Rehabilitation: Marguerite / Sue
3. Clinical Reports: Tamara / Mel
4. LOINC Modifiers: Rob
5. Medications: Larry/Bertha/Mattie
6. Implementation Guide: Mike Cassidy
7. Ambulance: Mary Lynn Bushman
8. Laboratory: Mindy DeLuca / Matt Klisher
Booklet Editing Review
The Relma database being passed around (CD provided by Jim McKinley) provides more functionality than is needed for the booklet review/updates. The web version limits access to most areas, so this version allows additional access that you won’t see otherwise.
Before the group gets started, Jim will review the checklist so everyone is on the same page.
1. slkdjf
2. LOINC Structure for each attachment type
3. Relma database: critical to Laboratory review. The structure was too difficult to include the structure in item 2 above (LOINC Structure for each attachment type). Available from Jim’s disk or the website.
- Click on View HIPAA Attachments (same as that at rgnfuse.regenstrief.org). Click on Ambulance Attachment
- Map to Local Terms : clear inputs, clear most limits, Lookup
Term by # (enter LOINC code). You have to confirm every LOINC to the database.
The RELMA does not include the long description. Use rgnfuse.regenstrief.org can validate the LOINC code.
DISCUSSION: Jim’s list of ACTION ITEMS FOR DECISIONS,
1. Find out if some
2. (COMPOSITE) and (NARRATIVE) should be expressed, but what about (TEXT) or (IDENTIFIER)?? Examples are found in Rehab booklet, LOINCS for.. WILL ASK KEPA for a better understanding EXAMPLES: 29194-8 (text), 29195-5 (identifier). Additional discussion: this has been an ongoing discussion. DECISION: A. get guides ready. B. make the guides pretty (this is a “B” change). STATEMENT: remove the TEXT & IDENTIFIER from the Long Common Name. In the RELMA database, verify the data type is correct (for Complex). The data type must be correct (stress in the IG); eventually add that paragraph to each AIS.
3. Should UPIN references remain? CMS has stopped assigning UPINs. (Offline: Marguerite see if balloted comment requested it be removed.). We agreed that a comment to such will remove it from the guides with a ‘clarification’ added in the Implementation Guide. ANSWER: Comment response to add verbiage: NPI required when used for HIPAA covered transactions for those entities that qualify for an NPI.
4. Date Range Of… the (FROM/TRHROUGH) is inconsistently used in the IG and in the database. Do we care? ANSWER: At a minimum, we will identify the instances and review to determine if FROM/THROUGH makes sense.
5. Evaluate the Data Type codes, and update our table in the IG, as well as verify data types in Rehab and other appropriate guides. EXPLANATION: data type codes are a product of the ASIG, not Regenstrief (per Dan Vreeman). Jim doesn’t know if the data type value is correct or not. His concern: HL7 Data Types, Release 1.0, December 2003, (ANSI/HL7 DT R1-2003) is not to be found, anywhere. Data type issue is huge. Believe the list is comprised of the codes that the ASIG wanted to use. ROB ROOT: Ask Keith Boone/Deb Belcher if the list is comprehensive, or just the list the ASIG was going to use in the booklets. Once we know the list is complete, we have to update the documents. If the list is not complete, we need to know what is missing so we can update the tables.
[END OF Q1]
Tuesday – Q2
Booklet Editing Review
An email from Daniel Vreeman & Gunther regarding Data Types explains their position on the question posed: : HL7 Data Types, Release 1.0, December 2003, (ANSI/HL7 DT R1-2003). Their explanation is not
Issues:
6. 52174-0 is present in the Relma database as a composite, and 52175-7 is in the database, but not in the guide. Jim will research.
Jim has paper copy of the guides. Wherever there are discrepancies, mark them with red markers.
Checklist for Booklet Editing:
1. Note if data types are different between the guide and the database.
2. “LOINCs” or “LOINC Codes” : grammar decision. Rehab, section 1.2
3. Cardinality: circle on guides
4. All numbering within text needs to follow the rules
5. Make sure items in parenthesis are correct. i.e. what’s in parenthesis should be in parenthesis and there are both the left paren and right paren (pairs).
6. Check acronyms to make sure they are spelled out at least once before use. Make sure the format in your document is consistent throughout.
7. Verify all references: Internal = (tables, other sections, other guides), External = (websites, OID’s, etc).
8. Verify XPath statements use correct LOINCs (i.e, LOINC changed but XPath not updated) => Follow-up w/ Deb Belcher
9. Remove the red item note that says, “This item spans more than one page below”
10. Inspect for ALL LOINC TBD’s, and determine how to populate.
11. UPIN – amend language in the response codes section (or appropriate section) where the notation to obsolete in 2nd quarter of 2007 is found. Amend to say “was” amended.
12. Verify ALL references to NPI: Insert language: NPI required when used for those entities that qualify for an NPI.
13. Verify ALL Response Codes are accurate (far right column in guides)
14. Replace all reference to MD with physician. (NOTE: we need to keep \a running linst of LOINC updates for Kathy Mercer).
15. Verify componenets are in column 1 (left justified), and are bolded… confirm ALL Answer parts are in column2 (right justified), and un-bolder. (Note: also verify descriptions associated w/ Comonents are BOLDER).
16. Verify ALL SNOMED CT external code-set values (i.e. prognosis for rehab, 170969009 POOR, BAD, etc. (According to January Orlando revew, a value for was found.)
17. ALL DATA TYPES SHOULD BE RE-VERIFIED AGAINST THE DATABASE, AND SHOULD BE ‘COMMON SENSE’ TESTED FOR CORRECTNESS BASED ON THE FOLLOWING TABLE FROM THE IG. The guide should be checked first, turning on the review-markup view to see if Jim changed per last meeing… then compare on the LOINC database … (my version: Data type: decide if the booklet is correct or not; based on the determination of the booklet, if different than the database, have to let Kathy know.)
18. Apply language about Value Table Layout to all guides (i.e. where component and answer are described, their columns, bold, etc). See Below extract from Rehab Guide.
19. Identify Date Range of statement and determine if FROM/THROUGH makes sense. If so, note to add, and make sure noted to be a database change as well.
20. Any guide that references “Other Provider Identifiers” as defined in theResponse Code section should include language to indicate the need for an OID to be obtained, and reference the appropriate section in the Implementation Guide.
Keith Boone (email reply to Rob Root): 1. the data types are from CDA R2; 2. the table covers all the data types in the booklets; 3. the table are complete; 4. Gunther has given you good information on the data type specs.
[End of Q3]
Tuesday Q1
Daniel Vreeman emailed Rob. The cardinality request of x..x was made during the Orlando meeting (January 2009), and is consistent with that used in the industry. The data is stored RELMA in a different format and Regenstrief has to convert it to this format. Also quoted Wikipedia.
Worker’s Comp in TX:
Vreeman : Attachments in Worker’s Compensation
Not Structured Attachment, the human variant. Showed breakdown of the attachment ( submitter, receiver, patient, claim, attachment type, question asked by payer, response from provider. Sending structured text that is not codified (uses tags). Or use codified attachment: the BIN segment of the 275 includes all the codified tags/data). Goal: industry to use codified.
The Data Structure: 275 Transaction set: (submitter, receiver, patient, attachments(s) : control number, type of attachment; claim or service line control number; procedure code, served date, format=HL BIN segment w/ MIME headers, boundary, CDA,
Worker’s Compensation: keyed on the CAT02 element. (Some implementations are working between clearing houses & xxx today. The CAT02 identifies to use HL for HIPAA. Use IA for electronic images, but must not be used under HIPAA. Therefore, you can put anything you want in the BIN segment. The 275 is the same. The format code = IA. The BIN segment contains a MIME envelope w/ multiple images (base 64 encoded) and no HL7. This implementation is in production today by 2 clearinghouses.
Another set of clearinghouses are using this. Format = IA. Bin segment = image (base 64 encoded). Repeat the loop for every image. Simple implementation. No migration path from here to the HIPAA attachments.
UHIN Attachments: Website : standards. Using HL7 messages. Don’t need the 275 to send the HL7 messages. Don’t need MIME either.
? from Durwin ? Answer: the count in the BIN02 continues to be a problem. The length between BIN01 & BIN02 don’t match.
History vs. today: 15 years ago, HL7 wasn’t ANSI accredited. Will accredit HL7 if they don’t overlap w/ X12. HL7 = intra-institution use. X12 = inter-institution use. HL7 has become an international org, not regulated by ANSI, and have created inter-institutional uses. HL7 is widely used over the internet (but not using 275 transaction to do so).
Alternatives: implementation today of WC using 275 for MIME encapsulated images. The 275 MIME – images & 275 – images being used by WC today. An email w/ an attachment, you are automatically sending MIME + attachment. Also a very widespread implementation of Images being ….
? Mary Kay McDaniel asked me, “Why can’t we send the base 63 image inside the XML? “ That can be done. Theyre are more options than what we have.
One of the biggest implementation today has keyed on sending images w/out HL7 or 275. The internet allows images being sent all over the place. It is time for the ASIG to look at this and consider it for the future.
TOM HUGHES: our company has not used the 275, because we agreed we wouldn’t use anyting that isn’t set in stone. At that time, we will do the
INGENIX: a WC clearinghouse has implemented attachments under HIPAA. Two other clearinghouses have executed the alternative. In TX, there is a requirement to use 275 for attachments, but doesn’t specify its use under HIPAA.
Durewin: the 277 request, is that being implemented in TX? Answer: in WC, it is always unsolicited. The images they require are WC related; some sort of report or treatment plan.
MLB: is the WC information being exchanged? ANSWER: From provider to payer. If going to state, the payer sends it. MLB: most payers all have EDI and translators, and are set up to use the 275.
KEPA: in WC, the payers are capable of using EDI. IN general, they specify a flat-file format they have created. Volume is low. Kaiser is probably largest in the world.
TOM HUGHES: almost always a scanned piece of paper. Basically forms. When a Rx is requested (PT or something else).
TAMARA: how do you know what they are getting if the don’t use MIME or CDA? Is it always the same files? ANSWER: human decision review, no automation, due to low volume.
MLB: that is why they don’t need the header information because it is all manual? Wouldn’t they want to automate it? If we allow them to do so w/out HL7 & the 275, it makes it easy to keep them out of it.
KEPA: the alternative is FAX. They will get an e-bill, FAXED, and someone has to match it up. Agree, the migration becomes more difficult.
MLB: I believe we want to get to an automated place, we should educate the industry the proper way to go.
KEPA: regarding UHIN, one of things they are doing, where they is a repository of info, the payer will ping the repository w/ a request to get all the information they need (30 years down the road), and will receive a 275 in return.