Project Description



Methadone File SpecificationVersion 1.1Table of Contents TOC \o "1-3" \h \z \u 1.Project Description PAGEREF _Toc530490032 \h 31.1Background PAGEREF _Toc530490033 \h 31.2Overview PAGEREF _Toc530490034 \h 31.3Technical IT Details PAGEREF _Toc530490035 \h 32.File Concepts PAGEREF _Toc530490036 \h 32.1File Definition PAGEREF _Toc530490037 \h 32.2Schedule vs. Actual PAGEREF _Toc530490038 \h 52.3Daily File PAGEREF _Toc530490039 \h 52.4File Name PAGEREF _Toc530490040 \h 52.5Centralized Hosting or Cloud Based Clinic IT Providers PAGEREF _Toc530490041 \h 53.Field Definitions PAGEREF _Toc530490042 \h 64.Upload Options PAGEREF _Toc530490043 \h 94.1Manual Upload PAGEREF _Toc530490044 \h 9Project DescriptionBackgroundThe State of New Mexico has requirements that each Methadone Clinic in the State send a daily file to the State that contains each person’s daily dispensing and treatment. The governing background for this program is not covered in this technical document. The payer is not relevant, (i.e. Medicaid). All treatments are expected to be in the file. Please get further details from a qualified State of NM source outside of this technical document for clarification.OverviewThis document defines a file format specification for NM based Opioid Dependency Methadone Clinics that can be sent to the State of NM, recording dosage and dispensing information on a daily basis.The data in this daily treatment file would be private personally identifiable confidential information.Technical IT DetailsThis is an IT technical document by IT developers for IT developers. It does not convey any State of NM policy that could be inferred by reading this spec such as a CPT code or approved drugs for treatment. The documentation in this technical spec of a code does not imply that the method of treatment is approved within NM or for NM programs like Medicaid.Method of File Transmission is not covered in this document.This document uses a flat file context in describing the layout. Alternative future transport layers may be made available, but the field definitions would stay the same.File ConceptsFile DefinitionThis is a flat file. Pipes are the preferred delimiter.The typical CR LF [(LF, 0A, 10, \r) (CR, 0D, 13, \n)] or just LF (\n) characters are strongly recommended at the end of each record. No File Header Record, No End of Batch Record.Extra Blank Lines would be ignored if present.Each record is self-contained and not dependent on a file level context. Each record has an explicit begin and end independent of the CR LF New Line concept. The traditional New Line \n or CRLF concepts at the end of a record are still recommended.The last separator (above example) is optional. Double quotes around a field will be ignored.Case Sensitivity of the Inbound File or Record will not matter and may or may not be mas and Tabs may be supported instead of pipes but this is not as reliable, especially with name and address fields. Please double check with the State before proceeding with commas or tabs.Pipes are preferred as the delimiters for a flat file.There is no distinction between blank and null. Also Literal strings with the characters NULL will be changed to blanks. Try not to rely on this behavior. Many numeric fields will treat 0 as similar to null. The above is discouraged but will be treated as blanks. In almost all cases it is better to send a blank field as opposed to hardcoding a value that would be in your records, especially regarding details around the medication and dosage. Blanks often map to “not sure” and unknown in the state systems.Schedule vs. ActualThe file should reflect an actual event after the fact. It should not reflect an “as scheduled”. So a No Show should not be in here or have an explicit service code combination that shows no service or that shows 0 milligrams dispensed. Having No record is preferred for a “no show”.Daily FileThis is is expected to be a daily file. The state systems are setup to recognize exact duplicates in the case of double submits and are not expecting files and records in any order. There is no assumption that all of the data in a file is from one day or that a day is only in one file. The records are individually processed. Some clinic systems may require nightly processing before the file can be generated and no assumption is made that the file is for the current or previous day. File NamePlease include an NPI or Tax ID or other unique location or clinic id in your file name. Also the date of the data in the file such as “20150106” for 06-Jan-2015. The First character of the file should not be a number. “CentralClinic199999999Daily20150106.txt” or something similar. Centralized Hosting or Cloud Based Clinic IT ProvidersIf a clinic is using a centralized system that has unrelated other clinics using the same system from a national IT provider then coordination is possible as long as all appropriate confidentiality and HIPPA rules and concepts are followed. (The clinic in NM would not actually do the pull and send of the file.) Field DefinitionsF01 Record Type – Start of Record – Format SpecifierThis is a literal hard coded constant value of “OTR1” for the first field of every record. The value could have double quotes around it.F02 Provider Code – NPI –TaxIDThis is a string value usually of a real world ID such as NPI or EIN or Federal Tax ID. This can be tightly related to the next field F02 Location. If a clinic is part of a multi-location single entity then this can be the ID of the parent umbrella organization, or unique to the location. Formatting such as hyphens or spaces will be ignored. F03 Location – Satellite ClinicThis identifies the location within the field F02 Provider Code – NPI –TaxID. If the F02 Provider Code was not unique within an organization then this field defines the actual clinic location.F02 and F03 together must be unique in the real world. It is very probable that single clinic scenarios will have the same value in both F02 and F03 or leave F03 blank. Blank maps to “main clinic”.At least one of the two fields F02 and F03 must be filled out. Formatting and hyphens etc. will be ignored for field F03. F04 SSNThis maps to the SSN in your system. This is not the SSN of the responsible payer or of a billing entity. This is the SSN of the patient and client. This needs to map to your explicit field used for SSN. This should not be an alternate “unique field” such as Med Rec. If you do not have an SSN field then leave this blank. If the SSN field is not always filled out in your system then blank is preferred to aliases you may use in your system for blank, like “123-45-6789”. All zeros (1 to 9 zeros) will be treated as blank. Formatting and Hyphens do not affect this field; your default format is OK.F05 DOB Date of BirthThis maps to the explicit DOB of the patient / client. A blank would be OK if the value is not filled out in your system for an individual person. A really old value before 1899 will be treated as blank. Formatting of the Date does not matter. Two preferred formats are 07/04/1776 and 04-Jul-1776. Almost any reasonable date string will be parsed correctly if it has a 4 digit year.SSN and DOB are critical keys to getting the records imported correctly.F06 First NameF07 Middle NameF08 Last Name (suffix optional here)Name Fields. First Middle Last.F09 Addr1F10 Addr2Addr1 and Addr 2 are the street and apartment addresses. They do not have to be properly geocoded or of a specific format. They are free text strings. F11 CityF12 State ( State 2 letter Code “NM” for example)F13 Zip Zip can be the 5 zip or the 9 zip. Formatting of the Zip can be your choice. Blank or Zeros are OK.F14 Drivers LicenseDriver’s License. This is a field that you would normally put a state or government id field into. There is no separate state of issue field. If the government id is not typically collected then this can be left blank. State of issue can be part of the field following your clinics conventions if there is only one field for state id. By convention for this file if you have a separate state id field please use the format “ST 12345678” or something similar. “NM 88888888” / “NM 999999999”. Do not hard code “NM”, only put data that came from your system. Your clinic system may treat this as free text and have varying formatting and state of issue conventions, this is OK.F15 Medical Record Patient IDThis is your Medical Record Number or a number tied to the patient within your system. Many clinics use conventions specific to their clinic in how they format and use this number. Please put your number here. This number is usually tied to the patient and does not change very often.F16 PCN or PAN (Patient Control Number)This is the PCN or PAN or a number that would define this Medical Event in your system. This PCN is often similar to an invoice id and is used in billing. Some systems may use the same PCN/PAN for a week of service and some systems may use a new number daily. This is your systems Patient Control Number. Side Note: There is no field in this file that is explicitly the patients’ provider id or insurance ID such as their Medicaid number or Blue Cross Blue Shield Number. However this provider id code may be what you actually have in your 15 MRN or 16 PCN fields which is OK. This file does not explicitly care about payer even though that may be what you use by coincidence four your clinics operations.F17 Service DateThis is the Line Level service date for a specific treatment. It is not necessarily the Billing Start Date. The format of the date field can be any reasonable date format. Blank and really old dates will be treated as null or blank.F18 ServiceTypeMay be tightly related to F19 for your system. This is your systems code for the type of service. This is usually used in one of two ways depending on how you use the (F19) Medication Type field.This is your systems concept of service. Counseling vs Medication Dispensing. It also may effectively define the Medication Type. This should be your own systems internal code for the servicing. It would be mapped at the state to the state’s internal code. It would be OK to leave this mon Service Codes for F18 could be “H0020”, “J0571”, “S0109”. You want to use a code that comes from your system for F18.F19 Medication TypeIf you use Service Codes like J0571 and S0109 which imply a specific medication type then this field could be blank. You can also use Service codes like J0571 or S0109 for field F19 in lieu of the previous field 18. You should use a code from your system for Medication Type or leave this blank. Both F18 and F19 together should define Counseling vs Methadone vs Naloxone etc. Even if one of the two fields is blank. Counseling services are not technically required to be in the file at this time so you may use a filter on your end to only put actual drug dispensing in the file that is sent to the state. F18 and F19 do not need to imply dosage amount explicitly or the format of the medication explicitly, they may if you use common well known codes or your internal codes that effectively imply amounts and exact medication physical formats.A detail about the state systems. If the combination of F18 and F19 do not explicitly convey a Methadone treatment (as opposed to bupeperdine) then the event will be treated as a presumed methadone treatment as opposed to an explicit methadone treatment. The state systems fall back to “probable” methadone.In short F18 and F19 should be common codes or codes directly from your system. See fields F20, F21, and F22 as well. The state systems may need some trivial configuration to map your codes if they are not common.F20 Service Line QuantityThis may always be 1 for clinics. It could be 7 if you were sending the file once per week and only had one record per week but even then 7 individual records would be preferred with a value of 1 here. It would be OK for this to be 0 or blank if some records were not a dispensing action. This can be a decimal number. Formatting and blanks are both OK. If take home dosages are given it would be expected that they might be on different records but it might be a 2 here for two days in addition to a 1 day liquid dispense.F21 Dispense Format This is Opioid treatment Clinic specific with no direct equivalent in a generic UB04 billing sense. This is your clinics code for the format of the Medication and may also imply the medication type. Pills vs Liquid vs Injection. Use your codes or a well-known code to differentiate between pills vs liquid. Leave blank if this is not easily available. F22 Dosage QuantityThis is the dosage in milligrams for this records event. Decimal numbers are OK. Blank or zero are OK.This should be the actual or scheduled dosage for this event. It should not be the current expected treatment level. It would be better to send blank or 0 and contact the state if this value is a problem for you or if you need clarification. Make sure that you do not put a value in here for “No Shows” that implies a dosage was given. Can be … 12.34567 ; 12 ; 12.0 with or without a “mg” designation. All values are always going to be assumed to be “mg” at this time. Up to 5 decimal places of precision are preserved.F23 SplitThis field indicates if the dose was split into multiple doses. A ‘Y’ or ‘N’ is accepted. Blank is OK only if F24 and F25 are also left blank.F24 TakeoutThis field indicates if the dose was given to the recipient to take home. A ‘Y’ or ‘N’ is accepted. Blank is OK only if F23 and F25 are also left blank.F25 Guest DoserThis field indicates if the recipient was administered the dose at a location which he/she does not typically frequent. A ‘Y’ or ‘N’ is accepted. Blank is OK only if F24 and F25 are also left blank.F26 Record End MarkerThis is a literal string constant of OTEND1 . There can be an optional delimiter after this field. New Line (LF) or CRLF is requested after this record end before the next record.Technical Background Note for Future readers of this file spec Document.Since the End of Record Marker is explicitly the Value “OTEND1” there is the possibility that future fields could be inserted just before F23 and after F22 Dosage Quantity. So the field F23 Record End Marker may not always be the 23rd field in the future for all files for all clinics.Upload OptionsManual UploadThe BHSDSTAR website will also include the ability to manually upload files. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download