06-03-2014 03:27 AM
I am trying some transport files with SAS@ University Edition. These files are in wlatin1 encoding. My session encoding is UTF-8. It causes that I cannot import the transport file into sas library. Do you know how to change the default encoding to wlatin1?
filename trans "/folders/myfolders/C2110H2R" encoding="wlatin1";
proc cimport LIB=WORK infile=trans isfileutf8=false;
You can get a sample transport file in attachment.
06-03-2014 04:29 AM
You cannot change the session encoding with SAS-studio analytics-u,
This could be done by a platform admin support multiple appservers defined at the metadata-server.
This is closed by the virtualized environment. You are running in the key "sasdemo" by default.
The cport / cimport approach is for migrating all SAS-types (catalogs included) wit associated limitations.
When you are just wanting SAS tables you are not needing cport/cimport as SAS datasets can be read (z/Os classic as exception) Moving and Accessing SAS(R) 9.4 Files (strategies) Would advice using different folders for different versions foreign format daatsets. The native format is the one belonging to your running session. Moving and Accessing SAS(R) 9.4 Files (CEDA limitations)
06-03-2014 06:07 AM
Hi Jaap Karman,
Thanks for your idea about another strategy for moving SAS data - CEDA. I reviewed about it.
"CEDA is a simple strategy for file access across a network. CEDA enables you to read a network-mounted SAS file from any directory-based operating environment that runs SAS 8 or later, regardless of the file format of the SAS file being accessed" from SAS document.
However, it doesn't meet my problem. The problem is that I have some cport transport files that come from the external site http://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Risk-Adjustors-Items/Risk2014.ht.... Its encoding is wlatin1 while the session encoding in SAS® University Edition always be utf-8. Do we have any way to get data from the wlatin1 transport file in SAS® University Edition?
06-03-2014 07:02 AM
I could see the dataset was created with 9.2 (header of file).
Searching for your experienced limitations..... Base SAS(R) 9.2 Procedures Guide . It is documented with the solution to start SAS with an other encoding.
That is a problem with this analytics-u version as being blocked. Let us see what SAS people will respond.
The only approach I can see is someone will do the latin-1 utf8 conversion of sas-files for you. (by teh way, I am not a SAS-insitute person).
06-07-2015 03:24 PM
I have downloaded the HHS-HCC SAS macros and data files for the HHS-HCC risk adjustment methodology software. The format .TRN file CIMPORT works out of the box, but the coefficient CIMPORT will not work because of the wlatin1 encoding. I tried many work arounds, but nothing worked. I even tried to send VMware Player a modified http request with LOCALE=es_MX in the request, but SAS Studio initialized with UTF-8, not wlatin1. I am afraid that unless CMS CPORTs with UTF-8 (fat chance, but hope springs eternal), or we somehow get hold of a coefficient file already imported, we will not be using SAS University Edition to be running our models. I hope the SAS support techs can find a work around.
06-08-2015 01:32 AM
On top of the encoding problems, I would not be surprised if your macro collection uses SAS modules that are not included in SAS UE. Keep in mind that UE is made for a very restricted set of learning tasks, and cannot be expanded/changed, not even by SAS TS.
06-08-2015 12:01 PM
It appears from this web site https://www.cms.gov/CCIIO/Resources/Regulations-and-Guidance/Downloads/ra-instructions-4-16-13.pdf that the HHS-HCC macros available from the Centers for Medicare & Medicaid Services (CMS) site are meant to be used for analysis of data collected regarding Medicare/Medicaid usage. I do not have access to these SAS macros for use, so I am not sure what SAS components they use. It is entirely possible that you will find the Macros do use SAS components that are not part of the University Edition. But you will have to investigate the SAS Macro programs by reading the CMS documentation to determine whether you can do any of the risk analysis using the SAS University Edition.
It says on page 2 of the above documentation from CMS that you should direct questions regarding the model instructions to HHS HCC Risk Adjustment Models at email@example.com If you are working with a professor, then I would assume your professor has already investigated the issues involved with using SAS University Edition and the CMS data and SAS macros. You would need to verify this with your professor. If you are doing this for a job, then it might be better to use your work installation of SAS for the macro execution, because it is likely that your work installation has more of the SAS components than the University Edition. Remember that the SAS University Edition is designed for non-commercial learning purposes and does not have the full suite of analytic components that might be available in a work situation.
06-08-2015 07:39 AM
I think that you can now change the session encoding in SAS UE via the preferences settings.
You will probably need to re-start the SAS session if you change it.
06-08-2015 12:13 PM
I believe the preference setting affects text files that you open/save from the SAS Studio interface. I don't think this changes the session encoding (ENCODING option) in your SAS session.
06-08-2015 07:12 PM
Too bad. I thought I read they were going to make so that users could change the startup encoding setting.
06-08-2015 08:38 AM
I would be surprised when it would be possible by just changing preference settings. The reason is there are also other loadable needed. That is adjusting or changing The os level script to the utf8 ones. Only a change within sbcs is not changing the number of bytes. That is only mixing the several Latin1 encodings that are existing eg Norway and Spanish. Not adding Arabic or Chinese.
06-08-2015 05:24 PM
Thank you Kurt, Tom, Jaap, Cynthia, and Chris for your help, all well taken.
Chris is indeed correct, the preference settings do not help. WLATIN1 is not one of the available options, in any case.
To Kurt and Cynthia, your comments are on point and investigating the HHS macros was part of my decision to pursue SAS University Edition. Cynthia's comments regarding questions of the HHS risk adjustment model are true, such questions should be directed to the mail box given by the CCIIO instructions. My intent in posting to this community thread was to seek a work around for the encoding problem, which seems to me to be intractable, but not in the domain of the CCIIO. As to the limitations of the University Edition, I investigated the HHS macros before I downloaded SAS and VMware software. The HHS risk adjustment methodology is complex and is described http://www.gpo.gov/fdsys/pkg/FR-2013-03-11/html/2013-04902.htm and http://www.healthcarereform.ny.gov/timeline/2012-05-11_exchange_stakeholder/cciio_risk_adjustment_ov..., the latter being a power point presentation. Basically, HHS has done all the heavy lifting as far as raw data analysis. The SAS macros, those used in the public risk adjustment released, are really simple. The risk adjustment model software is just a big decision tree, with regression coefficients in a TRN file and decision variables and constraint rules encoded as IF statements in the internal and external SAS macros. I think INC and SET are about the most complicated modules used. After all the enrollee and enrollee diagnostic data are run through the decision macros, the model uses simple addition and multiplication of score factors to compute the final, desired risk adjustment scores. Unless something like SET is not available, University Edition should be just fine.
Having said all that, one can see why achieving a successful CIMPORT of the regression coefficients from the TRN file is so crucial, while failure to do so is fatal. I really do welcome all the comments posted and thank you all for your patience and your help. As an aside to Cynthia, my work is self-supported in an effort to build a non-commercial, public access web site for certified CCS and CPC coders doing HHS hierarchial condition (HCC) coding from patient medical records. Such coding is part of the data foundation for the HHS risk adjustments mandated by the Affordable Care Act, but few web sites exist to educate and train experienced coders in the fundamentals of HCC coding and score calculations. Such web sites that do exist are not built by and for medical coders. I had hoped to integrate the HHS SAS code into a pipeline starting with the medical record and ending with a risk adjustment score. All my work is open source.
Peter Cooper, BA, CRT(RT), CPC
06-09-2015 01:23 PM
Thanks for the additional info. I wonder whether the CMS would be interested to know about the issues with the macro programs they've published for their risk models. They either have a reason for the encoding they've chosen (they might expect, for example, that this kind of macro program would only be used on a certain kind of SAS configuration) or it didn't occur to them that they might need to offer the programs to run on different types of SAS configurations. Either way, it might be better to work with CMS to get a set of macros (that they've "blessed") that can be used on the University Edition. It just seems to me that folks who are doing "HHS hierarchial condition (HCC) coding from patient medical records", as you describe would probably be performing these functions at work, using their work's SAS installation.
In a past career, I worked for a health insurance company and we would not have been allowed to use an external web site for any work with internal patient data.
06-10-2015 03:25 AM
Cynthia, CMS has chosen to make data public available in a dedicated SAS format. The reason could be ease of use an trustworthy distribution. They did that in the Era of Latin1 and US enlist world. As the world got bigger as just US we are all moving to utf8. The CMS choice of property SAS types could stil work as migrating Latin1 to utf8 is easily possible.
Then SAS decided to have that migration blocked with cport cimport. That makes the intention of CMS not valid anymore. Are you saying they should drop SAS usage for that? Promoting different standards for education and research...
06-10-2015 08:19 AM
Jaap, I'm sure that's not what Cynthia is saying. I agree that even US-centric data centers are using UTF-8 as a way to handle the growing diversity of national characters within our data sets. Perhaps the team that generates these specific catalogs could consider creating a version that is compatible with a UTF-8 session encoding -- I think that's the main point of Cynthia's suggestion.
Or, alternatively, perhaps some of us who have access to multiple SAS sessions could offer to convert the WLATIN1 version to a UTF-8 version, if possible. I'm unsure of the process for that, but I think it would also require permission from the folks who created the original.