Methadone

Project Description

Background

The 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.

Overview

This 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 Details

This 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 Concepts

File Definition

This is a flat-file.

Pipes are the preferred delimiter.

Open

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.

Open

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 preserved.

Commas 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. Actual

The 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 File

This is expected to be a daily file. The state systems are set up 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 Name

Please 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 Providers

If 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 off the file.)

Field Definitions

• F01 Record Type – Start of Record – Format Specifier

  • This 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 –TaxID

  • This 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 Clinic

  • This 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 SSN

  • This 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 Birth

  • This 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 Name

• F07 Middle Name

• F08 Last Name (suffix optional here)

  • Name Fields. First Middle Last.

• F09 Addr1

• F10 Addr2

  • Addr1 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 City

• F12 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 License

  • Driver’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 clinic's 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 ID

  • This 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 system's 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 for your clinic's operations.

• F17 Service Date

  • This 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 ServiceType

  • This may be tightly related to F19 for your system. This is your system's 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 system's concept of service. Counseling vs Medication Dispensing. It also may effectively define the Medication Type. This should be your own system's 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 blank.

  • Common Service Codes for F18 could be “H0020”, “J0571”, “S0109”. You want to use a code that comes from your system for F18.

• F19 Medication Type

  • If 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 Quantity

  • This 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 an Opioid treatment Clinic specific with no direct equivalent in a generic UB04 billing sense. This is your clinic's 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 Quantity

  • This 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 an “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 Split

  • This 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 Takeout

  • This 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 Doser

  • This field indicates if the recipient was administered the dose at a location that 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 Marker

  • This 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 Options

Manual Upload

The STAR website will also include the ability to manually upload files.