HMIS Schema Tickets (77 matches)

Reported by eric, 23 months ago.

change Housing Status 1 = Literally homeless 2 = Imminently losing their housing 3 = Unstably housed and at-risk of losing their housing 4 = Stably housed 8 = Don’t Know 9 = Refused

Reported by eric, 17 months ago.

SAS has a version of 8.63.00, which doesn't validate.

Reported by brian sokol, 2 years ago.

McKinney? Vento Funded is used for HIC

Reported by Val Pugh, Northrup Grumman, 11 months ago.

This will help systems that do not collect address information, or just partial addresses. For example, to get IsLastPermanentZIP populated, more than just the ZIP is required. For now, they must put in empty strings in those fields.

Reported by eric, 3 years ago.

"it is useful to know if a SiteService? in the import file is an SHP (or other) HUD grants. There should be a field to designate that. For now, since the SiteServiceType? for HUD Programs must be one of the code 1-6 and not 7-Other, we can use the SiteServiceTypeOther? field set to "HUD SHP Program" to indicate this, however a specific field, like HUDGrantType, which can be left out if not a HUD Grant, would be better " -David King

Reported by Jiwei Fan, 3 years ago.

perhaps a minimal and maximal version?

Reported by Tien Lum, 3 years ago.

in the ServiceEvent? element it would be nice to have some mechanism to track arrearage payments as that is currently needed in HPRP.

Reported by Matt Simmonds, 3 years ago.

Add an attribute to the XML specifying the case manager ID which updated/created the information.

Reported by David King, 3 years ago.

Possibly the reason for adding SiteService? as an element of Export was

to include these elements as hmis:SiteService.

Yes, that's why. And also so a SiteService? can be minimally sent without the whole parent hierarchy, and relying on IDs instead (using by reference as opposed to by context).

Reported by David King, 3 years ago.

Then the SiteID reference to a Site within an Agency would have meaning and would provide the linkage and extra data elements needed. If this was the intent then the annotation of SiteID referencing Parent Site is misleading. When included as Export.SiteService?.SiteID this is a reference to Agency.Site.Key which would not be the parent.

...Maybe the word "Parent" in the annotation is problematic. I didn't mean a higher level site than the ID'd site; I mean the Site element that is the conceptual or actual parent of the SiteService? element. All change the language to be more clear about that.

Reported by David King, 3 years ago.

Still question why Site is an element of Export since it has no reference to a parent agency and provides ambiguity and possibly confusion as to when to use Export.Site or Export.Agency.Site. The later would include a reference (via parent) to an agency and would seem like to preferred choice. Perhaps it is included since you have added the deleteStampGroup which would provide a mechanism to for deletes?

That's exactly why. I'll document that also. In the future, AIRS will have a deletion flag of its own, and we can drop this. -Eric

Reported by eric, 3 years ago.

4.15H Does not have and 'other' option. If it won't, nix the free text field. -Eric

Reported by Matt Simmonds, 3 years ago.

What contradicts this however is that in the Discharge Status question there is no response value for "Active" or "Not Discharged Yet" so I don't know how to classify them. Someone in the reserves that gets called up and serves a tour of duty and then comes back to no home, or in need of HPRP help, but has not been discharged but would be a veteran, right? Or am I missing something? If they are considered a vet do they use "other" for discharge status?

Reported by eric, 3 years ago.

from matt: Frequency is the same as quantity in the CSV as if it is recurring this just tells them how many times it recurs.

from eric: I like the frequency idea, but it sort of forces the XML parser to become more intelligent. If it sees a quantity of $100 and a frequency of 4, and the data model of the destination database is simple (no frequency tracking), 4 complete service records will have to be created. If we leave the grequency out of the XML, they can just send 4 ServiceEvent? records of $100 each and the XML processor can just dumbly shred it. I'm just worried that vendors will dutifully implement frequency. But if they're requesting this, I'll gladly add it.

Reported by Matt Simmonds, 3 years ago.

with picklist, extensible for local funding streams

Reported by Matt Simmonds, 3 years ago.

Matt:

With financial assistance amounts I understand the approach but wanted to confirm that you are OK that it conflicts with how income is being tracked. With income the rule is that it is associated to the individual that is earning it. So if the person leaves the family then that income leaves with them. With HPRP financial assistance we just need to be sure that by associating it with each family member that the assistance provided to a family of four doesn't get quadrupled when it comes time for reporting. If that is the case we might just have to spell this out for vendors to ensure their reporting is working properly and takes this into account.

BES: The difference here is that (for the most part) this is income coming from the outside, and the income is lost if you lose that family member. E.g. if its employment income, the income is solely dependent on the wage earner. Or, you could actually have two wage earners (or two unemplyment checks) with different incomes to be added up. The HPRP asssistance, like, say a stay in a family unit, is tied to the entire household (or, at least, is not tied to one or another adult household member). Or, put another way, financial assistance is more like an attribute of the service, and the service is associated with the household.

Reported by eric, 3 years ago.

It's just a string...

Reported by David King, 2 years ago.

Not sure why you made FinancialAssistanceAmount? a required field as it is only used in a ServiceEvent? for HPRP grants. Also, not sure why FundingSource? is required, particularly since the important contained element FederalCFDA is not required.

I would suggest making these minOccurs=”1”.

ServiceEventProvisionDate? is also required, but is not used for all services therefore should be minOccurs=”1”.

To be consistent with other naming, it seems that SiteService?.ServiceID should be named: SiteService?.SiteServiceID.

Reported by eric, 2 years ago.

Thank you, Eric.

I had a call from our vendor today regarding RelationshipToHeadOfHousehold?. In our HMIS, we have the following choices: Self Spouse Partner Child Stepchild Other

Currently, the Schema includes: Child Spouse Other family Non-married partner

It appears that the way our Agencies are handling this issue when the HeadOfHousehold? tag = <HeadOfHouseHold?>1</HeadOfHouseHold>, or self, is to leave the tag/node RelationshipToHeadOfHousehold? out of the submittal.

I could not find any reference to this issue in the Draft Regulations. Is simply leaving the RelationshipToHeadOfHousehold? tag out the best option if the Head of Household is the Client themself?

Thank you, Gregg

On Tue, 2009-11-24 at 13:59 -0800, Rocheford, Gregg wrote: I could not find any reference to this issue in the Draft Regulations. Is simply leaving the RelationshipToHeadOfHousehold? tag out the best option if the Head of Household is the Client themself?

Gregg, you've got it. If the person is the head of household, no need to list them as a member with a relation to the head of household. Just use their ID as the head of household ID. I'll add this to the 3.0 documentation, since I get asked it a lot. -Eric

Reported by Matt Simmonds, 2 years ago.

On Fri, 2009-12-04 at 13:53 -0500, Matthew Simmonds wrote:

Instead of replacing "FundingSource?" I changed it to "FundingCategory?" and added the new field to capture the CFDA # but called it "GrantIDNumber" just in case programs get non-Federal grants that have tracking numbers.

Matt, I had just left it up to the implementers to extend if they want to do non-Federal, because ids on local grants opens up a whole new can of worms. I've seen it often where program administrators think something is a local grant because the county gave the money to them, when in reality it's federal. And then there is the issue of naming and ID consistency, which CFDA resolves for federal, so I didn't touch it. But, since you have included it, and because it won't take much work, I guess I could add an index and open ended name for "other", since that's probably how most people will extend it. Okay, yeah, I'll do that, and put in the documentation that the codes for other local funding sources need to be worked out between sender and receiver. I'll get my stuff done and post your/my RC2 revision asap. -Eric

Reported by brian sokol, 2 years ago.

for hic

Reported by eric, 2 years ago.

need to add

Reported by eric , 2 years ago.

not sure what that even would mean

Reported by eric, 23 months ago.

Member.PersonID shouldn't need a dateCollected

Reported by Gregg Rocheford, 22 months ago.

I was looking through the HMIS XML Version 3.0 Cumulative Package Overview and found that there is no, IV.B.3.f. In fact, there is no IV.B.3.g. or IV.B.3.h. either. It goes from IV.B.3.e. to IV.B.3.i.

Reported by eric, 15 months ago.

Valerie, I see what you're saying, and we definitely had a couple ways we could go with this. I think we've implemented it in a compliant fashion, though, as I'll explain below.

The most applicable part of the 2010 Final HMIS Data Standard is where it reads: "The HMIS may also be designed to automatically generate a “Yes” response where income amounts are recorded." In other words, transmitting a dollar amount in the XML could imply a "Yes" for the HMIS system receiving the XML document. That's why we made it a choice: so the schema disallows submitting a dollar amount within IncomeSourceAmount? when also submitting a 0 = "No" for ReceivingIncomeSource?, which would defy the Data Standard. We're not losing anything by having a choice, because have any dollar amount implies 1= "Yes" for ReceivingIncomeSource?.

You can never put a zero dollar amount in IncomeSourceAmount?, because Section 4.1 of the 2010 Final HMIS Data Standards reads "When a client has income, but does not know the amount, a “Yes” response should be recorded for both the overall income question and the specific source, and the income amount should be left blank." So if you record a dollar amount in IncomeSourceAmount?, it implies a "Yes" to ReceivingIncomeSource?, but an explicit "Yes" implies that the amount is not known, so it has to be a choice of completing either ReceivingIncomeSource? or IncomeSourceAmount?. Conversely, if ReceivingIncomeSource? is "No", there would be no need to enter an IncomeSourceAmount?. So having the choice gains us a little better validation enforcement, but still adheres entirely to the Data Standard.

I'll add to the documentation next revision, to enhance clarity. -Eric Jahn

Reported by Val Pugh, Northrup Grumman, 15 months ago.

need to move them over to documentation.

Val, You are correct that the anyURI for source *should* be a valid URI. I created this ticket to change this in a future revision, but I think your validator should only warn, not err on this issue for two reasons.

First, According to:  http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI

************* 3.2.17.1 Lexical representation The ·lexical space· of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732]. Note: Spaces are, in principle, allowed in the ·lexical space· of anyURI, however, their use is highly discouraged (unless they are encoded by %20). **************

Second, From your link, ************** Annotations do not participate in ·validation· as such. Provided an annotation itself satisfies all relevant ·Schema Component Constraints· it cannot affect the ·validation· of element information items. **************

So for these reasons, I think we should modify the schema for future revisions, but it's not critical, and your validator shouldn't be thoroughly checking these anyURIs, or at least provide a way to ignore this or just warn. After all, these are just {user documentation}, not {application info} annotations.

-Eric Jahn

On Fri, 2011-03-04 at 01:50 +0000, Pugh, Val (IS) wrote: Here’s the question I was unable to submit to Ask the Expert:

I've opened the XSD document in a parser which is throwing errors on every "<xsd:documentation source=" entry. The error is that the source is supposed to be 'anyURI'. The HUD HMIS XSD has text strings like "2010 HUD HMIS Data and Technical Standards, Section 4.15F", which are not considered valid. Here's the w3c reference:  http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Can we get the XSD without this issue? Thanks, Val From: eric@… eric@… On Behalf Of Eric Jahn Sent: Thursday, March 03, 2011 6:28 PM To: Pugh, Val (IS) Cc: Jeffrey Ward; Stefan Baumgartner Subject: Re: RE: EXT :Your Request Regarding Topic "Data Integration, HUD HMIS XML and HMIS CSV" Valerie, I'll forward this to tech support for the web page, but I'm not sure what he'll be able to do without more debugging info. Did you try to resubmit? Otherwise, just email the question to me directly. -Eric On Mar 3, 2011 5:44 PM, "Pugh, Val (IS)" <Valerie.Pugh@…> wrote:

Reported by Val Pugh, Northrup Grumman, 15 months ago.

Val, you are correct in assuming that "PersonID in the Household/Member? element maps to a PersonID in the Person element". There is no requirement, however, that any household members IDs have a corresponding PersonID within the same instance file. It could have been sent before in a previous XML upload to the receiving database. Or, it could have been pre-populated in the receiving database via another means (such as human web-based data entry). -Eric Jahn

Reported by Val Pugh, Northrup Grumman, 15 months ago.

Here's a link to the April 2010 style guide that defines some things, like the AIRS PreAddress?.

 http://www.airs.org/files/public/AIRS_StyleGuide_FinalApril2010_ResourceSpecialistVersion.doc

Reported by Val Pugh, Northrup Grumman, 15 months ago.

Val, I understand your point. Essentially, what you're saying is you'd like a more realistic example XML. We've mainly just used workbench tools to create valid (albeit unrealistic) XML. I logged your request for more guidance and thorough examples, though I can't guarantee it'll be undertaken in the short term because of priorities. A lot of the details of data integration have to be worked out between sender and receiver at this point, though a more exhaustive set of guidance would be helpful moving forward. Another big area we've left untouched to-date would be an HTTP messaging API (web service) describing how portions of HMIS XML could be send to request deletion of a record by ID. There is broad coordination going on within Human Services within the National Information Exchange Model for a more structured process of defining Human Services exchanges, but it's unclear at the moment how/when this will impact HMIS. -Eric

On Sat, 2011-03-05 at 00:49 +0000, Pugh, Val (IS) wrote: I'm afraid this doesn't make much sense to me. The Instance files showed PersonIDs in one section and PersonIDs in another section and none of them correspond to each other. In addition none of the HouseholdID values in the Household section match HouseholdID values in the SiteServiceParticipation? sections. I think this fact makes understanding the model even more confusing.

While the information could have been sent at different times, I doubt that would be the norm or the expectation, especially in the early days of the export/import process. I just want to point out that vendors are using these instance XMLs as models of what they should be doing and what data they should be putting in their XML files. I guess I just think it would be more useful to have more realistic (looking like real-life) data. We'll be pointing out the issue to the other vendor. Is there a guidance, though, specifically for vendors who are extracting data into XML? For example, to suggest that either the IDs have to match up or they have to be sure the receiving system already has the necessary information? Thanks, Val -----Original Message----- From: eric@… eric@… Sent: Friday, March 04, 2011 4:45 PM To: Pugh, Val (IS) Cc: eric@… Subject: EXT :Your Request Regarding Topic "Data Integration, HUD HMIS XML and HMIS CSV" Dear Val Pugh, We're happy to respond to your question (referenced below) with the following answer: Val, you are correct in assuming that "PersonID in the Household/Member? element maps to a PersonID in the Person element". There is no requirement, however, that any household members IDs have a corresponding PersonID within the same instance file. It could have been sent before in a previous XML upload to the receiving database. Or, it could have been pre-populated in the receiving database via another means (such as human web-based data entry). -Eric Jahn Sincerely, Eric Jahn **** Your original question was: "In the sample XML files - HUD_HMIS_Instance.xml and HUD_HMIS_AHAR_Universal_Client_Data_Only_Instance_Minimal.xml - there is an example of a household with members, each member having a PersonID. I would assume that the PersonID in the Household/Member? element maps to a PersonID in the Person element, but this is not the case in either XML instance file. Is this just a mistake or is the member PersonID different from the person PersonID? If they are different, how do we associate Person with Household?"

Reported by eric, 14 months ago.

Val, A Need element can exist within a SiteServiceParticipation? to positionally denote that the need(s) was captured within the context of a Program Participation. So Person.SiteServiceParticipation?.Need would be used in that case.

Alternatively, the Need can exist outside the context of a program. Say a disaster hits, and it is determined that a homeless person needs temporary shelter, but the person is not formally enrolled in any program. Then Person.Need is used.

So there should be a IV.B.3.f in the overview documentation for a Person.Need option, as well as the wrapped Person.SiteServiceParticipation?.Need described in IV.B.3.i..

The HMIS schema allows for the placement of a Need in either location. PersonHistorical? is similar to Need on this respect: they can exist either wrapped within or independently of a SiteServiceParticipation?.

With regard to #3, Need.SiteServiceID does refer to airs:tSiteService.Key, as you asked. That needs to be more succinctly stated in the docs.

Reported by eric, 14 months ago.

On Mon, 2011-03-14 at 19:31 +0000, Pugh, Val (IS) wrote: 1. IV.B.3.e.i (lower-case roman numeral I)?

Yes, that's a lower-case Roman numeral "i". I think it would help for next revision to show the whole IV.B.3.e.i string instead of just "i."

Reported by eric, 14 months ago.

and remove minOccurs="0 from "IncomeSourceAmount?"

Reported by Darin Patterson, 11 months ago.

Add this clarification to overview:

"Glad to hear you are moving forward with support for the schema! Since RelationshipToHeadOfHousehold? is not required,

<xsd:element name="RelationshipToHeadOfHousehold?" type="hmis:fourVal" minOccurs="0">

, just omit this element if the person is the HeadOfHousehold?. In fact, as you mentioned, if they are the HeadOfHousehold?, there is no need to even include a Member element, since it adds nothing aside from the RelationshipToHeadOfHousehold?, at least in the current version. So your second stated option of "... OR, A person who is identified as the head of household should be listed as the “head of household ID”, but NOT listed as a member (there is no additional information that would be gained by doing so)..." is correct. This finer point should be added to the docs, so I made a ticket for that at: -Eric Jahn

-Eric

On Wed, 2011-06-15 at 12:32 -0700, Darin Patterson wrote: I am currently working collaboratively with a community partner to

simultaneously test their XML 3.0 Export and our XML 3.0 Import. We've come across a question related to the intended use of the household element, described in detail below. Can anyone provide clarification for the intent? The household element includes: a unique household ID, zero or more Head of Household IDs, as well as zero or more members listed underneath the Household element. The question is which of the following rules apply: - A person who is identified as the head of household should be listed as the “head of household ID” AND listed as a member OR - A person who is identified as the head of household should be listed as the “head of household ID”, but NOT listed as a member (there is no additional information that would be gained by doing so). The standard includes a “member relationship” for each member to identify their relationship to head of household and there is no “self” as relationship available, so I assume that the head of household shouldn't be included as a member, but the standard doesn't require a relationship to be identified, so it is feasible that it is expected to simply include them in the member list and not identify the relationship. Any insight would be appreciated. Thanks.

"

Reported by eric, 10 months ago.

Need to add this to docs:

Export periods are mostly a rough way to group data into non-overlapping chunks, grouped by when they where collected. There could be some submitted data falling outside the period, because of back-dating of newly received records. Operationally, the export period is really a period of time over which new data was collected, not a period within which the data values must fall. So if you collected some new ContactsMade? data on a given date, that receipt date should be bounded within the enclosing Export tag's export period. But I could see scenarios where you'd want to use the export period differently, say, when migrating from one vendor system to another and sending chunks of XML by service/enrollment dates. The sending system might not track data collection timestamps, so service/enrollment dates may be all that are available for grouping the periods. So the main thing about export periods is that they are used as consistently as possible as a convenience feature so gaps don't occur or go undetected. The receiving side will still have to rely on deduping to ensure the same datum isn't stored twice. Hope this helps. I'll add this clarification to the next revision of the docs, when that revision occur.

Reported by Val Pugh, Northrup Grumman, 10 months ago.

"The ServiceEvent? element subelement names have apparently changed since the HMIS XML Version 3.0 Cumulative Package Overview was written.

Please indicate if the sub-element in the xsd corresponds to the item in the document as follows: *QuantityOfServiceEvent? is the same as QuantityOfService? *QuantityOfServiceEventUnit? is the same as QuantityOfServiceMeasure? *ServiceEventIndFam? is the same as ServiceUnit?

-Eric Note: yes, all these changes are correctly mapped

Reported by eric, 14 months ago.

The instance document admittedly doesn't have a very useful nor thorough IncomeAndSources? example element, so I'll add that as a ticket request for improvement. It is a valid instance, since if there is a minOccurs="0" in either of the choices, then both can be skipped.

Reported by eric, 14 months ago.

So, to cut a long story short, this is what I understand: If the IncomeAndSources? element is specified, there has to be at least one IncomeAndSource? element, for each of which there is an IncomeAndSourceID and at least one IncomeSourceCode?. And, for each IncomeSourceCode?, either ReceivingIncomeSource? or IncomeSourceAmount? is required.

...or neither ReceivingIncomeSource? nor IncomeSourceAmount?. They can both be skipped, because one of them has a minOccurs="0". But everything else you said was correct, just add that additional part. But, like you said the IncomeSourceCode? is required if you have an IncomeAndSource?. Maybe that should be optional also, so you could just send ReceivingIncomeSource? or IncomeSourceAmount? with its parent IncomeAndSourceID...

Reported by Val Pugh, Northrup Grumman, 14 months ago.

Val, What is the value of grouping data collection dates as a set? It just loses the accuracy the actual dateCollected provides, and adds no added benefit. If you want to group them together under a date set, I suppose you could just give them the same dateCollected date, but I'm still not understanding what the purpose would be. I'm guessing your thinking of a case management scenario where a client completes an interview, as a session, with a case manager and you want to group that session together, and perhaps attribute that session to a specific case manager? I could add that as a feature request. We really don't have case management features built into the schema, but having goals/action plans/assessment sets would fall under that. It's sort of a general human services feature set more appropriate to a more general human service XML NIEM is working on under its Human Services domain. But it's a nascent standards body, so there isn't anything usable there yet. If you know of any existing structures we can use for case management, I'd be happy to add them as feature requests. I've already logged this request, but I think it needs to be sold as a case management functionality feature. -Eric

On Wed, 2011-04-06 at 18:06 +0000, Pugh, Val (IS) wrote: Truthfully, the dateCollected attribute is not helpful. If they send us 10 elements and each has a different dateCollected, that still does not tell us when the PersonHistorical? information itself was collected (i.e., as a set). Hence the request for an Assessment Date. We are okay with that date being optional.

An assessment date at the PersonHistorical? level does not restrict "flexibility" but rather enhances it. -----Original Message----- From: eric@… eric@… Sent: Wednesday, April 06, 2011 12:01 PM To: Pugh, Val (IS) Cc: eric@… Subject: EXT :Your Request Regarding Topic "Data Integration, HUD HMIS XML and HMIS CSV" Dear Val Pugh, We're happy to respond to your question (referenced below) with the following answer: Val, Your understanding is correct that "Person Historical is associated with Site Service Participation if the assessment occurred in conjunction with program entry and exit". No, there was no specific vision that only a single PersonHistorical? element could be placed within a SiteServiceParticipation?. PersonHistorical? is just a collection of historically recorded facts/circumstances about a person, and there can be any number within a SiteServiceParticipation?. A second XML doc could transmit more PersonHistorical? elements for a given SiteServiceParticipation? ID, or for a given Person ID. As far as the concept of an assessment as a periodic review, and covering a defined period (such as Q1, Q2, Q3, monthly, annual, etc.) and reflected in the data model as pertaining to such a period, the Data Standards are ambiguous. "Annual assessment", "at entry", "at exit", and "follow-up" are mentioned in the data standards. We do have the "dataCollectionStage" attribute to track the "at entry", "during enrollment", "at exit", and "follow-up" milestones. But we have nothing except the dateCollected attribute to get at the timing of the assessment, and we leave it to the application's reporting logic to sort program quartiles, etc., by datestamp. I think this achieves the highest level of specificity and flexibility, without batching into time or other logical divisions, which would result in more elements and structure without really adding more information. Hope this helps! -Eric Jahn Sincerely, Eric Jahn **** Your original question was: "My understanding is that Person Historical is associated with Site Service Participation if the assessment occurred in conjunction with program entry and exit. Is it expected that there would be one Person Historical associated with the entry and one with the exit? The XSD doesn't enforce this, but is that what was envisioned when it was designed this way? My understanding is that when Person Historical is associated directly with a Person, it represents one of the periodic assessments described in the data standards and there could be multiple of them. However, there is nothing in the Person Historical structure itself to indicate that it was a "formal" assessment or when that assessment occurred. That is, subelements under Person Historical have dates, but if the agency is expected to make a yearly or quarterly assessment (based on the data standards), there is nothing in PersonHistorical? to indicate that the particular Person Historical record is for that assessment. At the least, an optional Assessment Date would be useful, I think."

Reported by eric, 3 years ago.

It makes no sense to have 2 or more.

Reported by eric, 3 years ago.

they weren't in the data standard, but the schema should provide them regardless.

Reported by eric, 3 years ago.

Should be hmis:unsignedInt, not hmis:integer, remove hmis:integer altogether

Reported by eric, 2 years ago.

...since it is the type of siteservice (program site)

Reported by eric, 3 years ago.

...to make parsing easier. Or only allow one DatabaseID per XML doc. It's too difficult to parse otherwise, because you have to look for the next database id, and DOM parsers don't like doing that. Sax parsers are probably more okay with it, but they have their own issues.

Reported by eric, 3 years ago.

So that if ServiceEvent? is submitted without a need, one can still attribute a SiteService?.

Reported by eric, 3 years ago.

Should be of type hmis:date currently is: <xsd:element name="SchoolLastEnrolledDate?" minOccurs="0">

Reported by Sherry Patheal, 3 years ago.

too ambiguous if just string. Especially for Address fields, etc., where it should be limited. hmis:string was never used in 2.8 XSD

Reported by eric, 3 years ago.

It could though, still be useful to have an effective date for, say, DOB. It could differentiate between two back-dated DOBs entered for the same person on the same day. The effective date could be the date the determination was made and the date updated would still be the date the backdating occurred. We'd have to elucidate this in the docs if we did it, and I think it would just complicate things.

Reported by David King, 3 years ago.

It has Site, but not Service, do only way you can transmit a Service is within a Site. But, one may not already have a Site assigned for a Service yet. -Eric

Reported by David King, 3 years ago.

according the UML, a PersonHistorical? can be unassociated from a SiteServiceParticipation? and just be associated with a Person.

Reported by eric, 3 years ago.

add AgencyIDs to Service and Site to link back up to Agency from Source.Export.Service and Source.Export.Site (this latter one can also be done with Source.Export.Agency.Site).

Reported by eric, 3 years ago.

also need to look at if HeadOfHousehold? and Members should be minoccurs = 1, but I don't see a definite reason. It would have to come from an AHAR/Data standard need to know.

Reported by eric, 3 years ago.

Not stuck on this, but might make things easier.

Won't fix, because sometimes the same ID could be set twice in XML file.

Reported by eric, 3 years ago.

like dob but, names can be changed, so not names. ssn would pertain. Also all the database and export ids. Do they need timestamps? Probably not.

Reported by eric, 3 years ago.

changed in HMIS 3.0 RC2

Reported by eric, 3 years ago.

a couple vendors have this and one requested it

Reported by eric, 3 years ago.

see 6/22/2009 conversation with David King:

On Mon, 2009-06-22 at 14:06 -0400, David King wrote:

Eric, I just noticed that the SiteID element of SiteService? is not required (minOccurs=”0”). SiteID is used to reference a specific Site in the AIRS XML file (Site.Key = SiteService?.SiteID). All ServiceEvents? must have an ‘owner’, i.e., agency/site that provided the service. Without a SiteID, the XML file could have ServcieEvents? without a specified provider. SiteID should be required.

David, The SiteService? in HMIS is really just a way to send some extra SiteService? (Program Site) information that HUD requires, like the CoC Code, that AIRS doesn't have within the SiteService? type in the AIRS 3.0 Schema. It not a replacement for a full AIRS description of a Site.SiteService? which is what you should be using to convey the Site.Key/SiteService?.Key linking for a SiteService? to a Site parent. So, in the AIRS Schema, Sites can have many SiteServices? nested below them. AIRS doesn't yet even have a Service type, which I think they need to add in the future. Right now, a Service in AIRS has no existence of its own; only as it is embedded as a SiteService? within a Site, but that makes the AIRS model more rigid than it needs to be. So I think SiteID should be removed altogether from the HMIS Schema, because AIRS XML should convey that relationship. The SiteServiceID is all you need to link to the SiteService?.Key in the AIRS Schema and go from there using AIRS XML.

So right now AIRS looks like this:

Agency

|

Site

|

SiteService?

But it should model it more robustly as:

Agency

| |

Site Service

||

SiteService?

where an agency can have many sites (locations) and many services (programs), which can recombine in any number of SiteServices? (Programs at many locations). But we have to work with the AIRS folks on that. For now, what they have works, but it's rigid and the code will have to work around that rigidity.

-Eric

Reported by eric, 3 years ago.

From David King on 7/3/2009: "I think allowing Needs/ServiceEvents? outside a SSP, as well as inside, is the right compromise and 'Usage Notes' should make it clear that for HUD Program Services, they must be included in an SSP record."

Reported by eric, 3 years ago.

Should be hmis:twoVal instead of unsignedInteger

Reported by Gregg Rocheford, 3 years ago.

Here's a trivial issue for you... I found that Subsidy is misspelled in this section. <xsd:simpleType name="destinationBase">

<xsd:annotation>

<xsd:documentation xml:lang="en">

Destination Type

. . . 19 = Rental by client, VASH Subisdy

Reported by eric, 3 years ago.

http://xsd.alexandriaconsulting.com/cgi-bin/trac.cgi/changeset/348

Reported by eric, 3 years ago.

so deleteStampGroup is not available there.

Reported by eric, 3 years ago.

So that one can send a Service that is Pre HUD Program. Say, for PIT info collection.

Reported by David King, 3 years ago.

To link the many-to-many Services to Sites, add ServiceID to Source.Export.SiteService?, next to SiteID.

Reported by David King, 3 years ago.

Need.SiteServiceID is type= hmis:id.

PersonHistorical?.SiteServiceID is type= hmis:unsigedInt.

ReleaseOfInformation?.SiteServiceID is type= hmis:unsigedInt.

ServiceEvent?.SiteServiceID is type=hmis:id.

siteServiceParticipation.SiteServiceID is type= hmis:unsigedInt.

I would suggest that these all be the same type, AND that they all be the same type as what they normally point to which is SiteService?.Key. In airs:tSiteService.Key is xs:nonNegativeInteger (in hmis .xsd file would be xsd: xsd.nonNegativeInteger).

Hmis:id includes the dateTimeStamp attributes, however, this is not needed by SiteServiceID as this element is always preceeded by another …ID which is an hmis:id which is adequate to define the dateTimeStamp attributes for the containing element.

David

Reported by David King, 3 years ago.

On Fri, 2009-11-06 at 08:13 -0500, David King wrote:

Eric, SiteID has the same problem -- it is defined in the AIRS xsd as nonNegativeInteger and in Event.SiteService?.SiteID as unsignedInt. However, since the AIRS xsd is actually ours, shouldn't all of these ID's be the same as hmis:id which provides for either a string or an integer. This would be even more flexible. David

David, Agreed. They should be the same, so I'll make SiteID nonNegativeInteger. In fact, I'll replace hmis:unsignedInt with hmis:nonNegativeInteger in all locations in the schema. I think nonNegativeInteger is very very close in meaning to unsignedInt, and the difference arise from the parent types each derives from. unsignedInt has a cap at 4294967295, whereas I don't think nonNegativeInt has that, since it doesn't derive from unsignedLong like unsignedInt, avoiding the cap. I'm trying to keep AIRS_mod from divirging from the regular AIRS schema, because then I break compatibility with existing AIRS 3.0 implementations, especially ones which don't implement HMIS functionality. For that reason, I don't want to make SiteID an hmis:id. -Eric

Reported by Pamela Roy, 2 years ago.

for situations where TypeOfServiceOther? is to be used.

Reported by eric, 14 months ago.

<xsd:element name="IncomeSourceAmount?" type="hmis:nonNegativeInteger" minOccurs="0">