HMIS XML Schema version 3 and the March 2010 HMIS Data Standards Revised Notice

[Eric Jahn]

HMIS XML 3.0 Release Candidate 4 files are available at:
http://tinyurl.com/yjgtrjo

Mostly minor changes/fixes since RC3, and the addition of a "Regions"
data type for optional regional reporting. RC3 incorporated the changes
seen in the March 2010 release. A change list is at:
http://tinyurl.com/yj3hhyd , changes 442-472.

--
Eric Jahn
Alexandria Consulting LLC
phone: 727.537.9474
3126 8th Ave N
St. Petersburg, Florida 33713

[Mary Schwartz]

Hi Eric -

 

There's a perception here in Washington that the 3.0 XML schema cannot handle multiple enrollments and exits into the same program in the same file because the program nodes define the programs with a program ID number, and the client nodes define what program they are in by that program ID number, but if you had the program ID number more than once in the program part you wouldn't be able to distinguish which client record went with which program.  Basically it doesn't "nest" the client nodes within each program node the record pertains to.  This is going to impact our recidivism reporting if we can't build files with multiple program entries/exits (like for emergency shelters).  Can you give me some advice on how to manage this if our perception is indeed correct?  Or correct me if I'm wrong?

 

Thanks
Mary

--
You received this message because you are subscribed to the Google Groups "HMIS_Data_Integration" group.
To post to this group, send email to hmis_data_...@googlegroups.com.
To unsubscribe from this group, send email to hmis_data_integr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hmis_data_integration?hl=en.

[Eric Jahn]

Mary,
What you're trying to do, that is "list multiple enrollments and exits into the same program in the same file", is readily achievable with the 3.0 HMIS Schema.  But before I explain, I saw a few terminology problems with your description of the issue, which may be causing some confusion. 

A "program" is called a "Service" in the Schema (the word program is avoided by AIRS, since it can take on perhaps 5 meanings as mentioned by David Talbot in a previous thread in this forum years ago).  A "program participation (entry/exit)" is a "SiteServiceParticipation" in the Schema.  This is all comes from AIRS' Agency/Site/Service model.  Here's a diagram of how it's all connected: http://xsd.alexandriaconsulting.com/cgi-bin/trac.cgi/browser/tags/HUD_HMIS_XML/HUD_HMIS_XML_3.0-RC5-final/class_diagram.png

There is no such thing as a "ServiceParticipation", only a "SiteServiceParticipation", which in essence enforces that a Service be connected to a particular Site to make a SiteServiceParticipation.  From the diagram, there is only a line connecting SiteServiceParticipation to SiteService (a program location), but there is not a line leading from SiteServiceParticipation directly to Service.  And that's why I think that you're coming to the conclusion that the 3.0 schema cannot handle multiple enrollments and exits (SiteServiceParticipations) into the same program (Service): because you're right, technically it can't handle *any* enrollments directly into a service.  It does allow one or multiple enrollments into a SiteService though, and that's what you want to do.  If the program is an online service, just make up a proxy Site to create the SiteService.  AIRS allows for "Siteless Services". 
 
So, to handle multiple enrollments into the same program, you just do something like:

...
<hmis:Person>
    <hmis:PersonID>
        <hmis:IDNum>2090888539</hmis:IDNum>
    </hmis:PersonID>
    <hmis:SiteServiceParticipation>
        <hmis:SiteServiceParticipationID>
            <hmis:IDNum>1</hmis:IDNum>
        </hmis:SiteServiceParticipationID>
        <hmis:SiteServiceID>444</hmis:SiteServiceID>
        <hmis:ParticipationDates>
            <hmis:StartDate>2011-03-21T08:00:00</hmis:StartDate>
            <hmis:EndDate>2011-03-22T12:55:45</hmis:EndDate>
        </hmis:ParticipationDates>           
    </hmis:SiteServiceParticipation>
    <hmis:SiteServiceParticipation>
        <hmis:SiteServiceParticipationID>
            <hmis:IDNum>2</hmis:IDNum>
        </hmis:SiteServiceParticipationID>
        <hmis:SiteServiceID>444</hmis:SiteServiceID>
        <hmis:ParticipationDates>
            <hmis:StartDate>2011-03-27T18:51:58</hmis:StartDate>
            <hmis:EndDate>2011-03-28T14:11:01</hmis:EndDate>
        </hmis:ParticipationDates>
    </hmis:SiteServiceParticipation>
...

The above XML snippet (full XML attached) shows a single person having two enrollments with IDs #1 and #2 for the SiteService with the same ID 444.

I also put a couple more responses inline below.  Please feel free to call me if you want to speak directly about this.  Hope this helps!

--
Eric Jahn
Data Architect

Alexandria Consulting LLC
phone: 727.537.9474

St. Petersburg, Florida

On Tue, 2011-03-29 at 07:36 -0700, Mary Schwartz wrote:

client nodes define what program they are in by that program ID number

No, translating your terms into HMIS 3.0 XML element names, Person (client) nodes don't have a ServiceID (ProgramID) child element.  Under Person, there can be zero to many SiteServiceParticipation children, which each have a SiteServiceID to define the program location.

but if you had the program ID number more than once in the program part you wouldn't be able to distinguish which client record went with which program.  Basically it doesn't "nest" the client nodes within each program node the record pertains to.

No, but it nests the SiteServiceParticipations elements under the Person elements