Expose XML Endpoint

[litlfred]

Background: The provider registry community is adopting the HPD profile from IHE for implementation in the short-term and is supporting development of the CSD profile (References Below). In both of these profiles you are allowed to query on provider and facility related data and it will make sense to cache the facility data from a Facility Registry. Our likely implementation scenario is that the provider registry will interface with the facility registry through the HIM.

High-Level Requirements:
_We would like to expose basic facility data in a manner that it can be easily cached by a another service ( e.g. get a list of all facilities, get a list of facilities changed after a certain timestamp, ...).
The basic facility data that we need is defined in the HPD and CSD profiles We would also like that this data be exposed in an XML format so that the data can be readily transformed via XSL into the format required by the target systems choice.Note, in our implementation scenario above, the actual transformation may be done at the HIM.
*_In the case of HPD, this is through DSML. **In the case of CSD , an update process for facility data has not yet been defined

I think that most of what we need is already exposed in JSON so we are essentially just asking for an XML format of the query result set.

References: HPD Profile HPD Examples CSD DSML Specification DSML Schema

[edjez]

Discussed today in the technical call. An XML version of the FRED API is the simplest aspect of that request and could be done rapidly. It would take defining the Facility object XSD and the extension of the API endpoint; and decide on whether to use an existing standard for the container (eg RSS) or roll a custom one ( @bobjolliffe long time ago said he preferred the latter, I'm inclined to the former as we could reuse the GeoRSS endpoint but it's not a major breaking point either way). We'll suggest an XSD based on the Facility Object for review in the upcoming days.

[edjez]

Editing for maintenance Next steps:

• Propose and review XSD for facility object & container
• Agree on endpoint extension (suggest .xml)

[edjez]

Notes from call: Bob will also fish out the RelaxNG schema and start playing/matching with what we have in Json We need to map to CSD required fields as prescriptively as possible. Martin will email with Bob to review and discuss the schema

[edjez]

Update from call: Martin will work on this this week

[litlfred]

Sorry that I wasn't able to join the call today. Was there a status update on this? Thanks so much.

[mverzilli]

Just committed an XSD and an example facility XML based on the JSON one at facilityregistry.org to start discussing.

[edjez]

Thanks Martin - can you provide an ETA for the API implementing it as a prototype?

Carl - see the xsd + example here https://github.com/facilityregistry/fred-api/blob/master/docs/facility_1.xsd https://github.com/facilityregistry/fred-api/blob/master/docs/facility_1.xml

I already have some feedback I didn't realize this morning - IMO longitude shld be named 'long'. For anyone that has worked with the geo namespace a lot it would be automatic to put the 'o' instead of using 'lng'.

On Jul 11, 2013, at 1:42 PM, mverzilli notifications@github.com wrote:

Just committed an XSD and an example facility XML based on the JSON one at facilityregistry.org to start discussing.

— Reply to this email directly or view it on GitHub.

[litlfred]

Thanks Martin and Ed. You can find a draft XQuery for CSD Directory compliance here: http://csd.ohie.org/svn/CSD/queries/exec/fred_conversion.xq

[bobjolliffe]

So far only had a brief look through Martin's xsd but it looks like the right direction to me. A few minor thoughts:

1. we might support a minorVersion attribute on the root element rather than assume that version is determined solely by namespace, so that when we move from 1.0, to 1.1, 1.2 etc namespace bindings are not broken and backwards compatibility can be achieved between minor version changes.
2. regarding identifiers, I would use attributes rather than child elements.
3. regarding coordinates we should be able to reuse a gml point type here.

Otherwise its looking simple, clean and fine.

Regarding CSD we keep a close eye on it as it too is still a moving target. Carl, do you have a list of issues arising from testing conversion with xquery/xslt tools. This will be the list we want to keep track of. There are some issues arising from where CSD is too prescriptive, but these I am sure they will have to relax, rather than impose them on fred or any other implementations. There are others (such as the representation of unique identifier as union of sensible types) where our fixation with uuid stands out as ideologically rather than practically driven.

[litlfred]

Sorry, I can't make the call today -- there is a IHE CSD call at the same time.

The newest version of the .xsd for CSD can be found here: http://csd.ihris.org/svn/CSD/CSD_July_25.xsd I think most of requirements from CSD on the facility side have been relaxed. I didn't really keep a list of any of the issues I had converting the FRED XML to CSD as 1) I didn't really encounter any and 2) I am really only cursorily familiar with your data model and the requirements of a FR and so was not in a position to really evaluate this. So please, take a look. I am not sure where you meant that it was too prescriptive.

For reference, this is the xquery used to convert the FRED XML to the earlier CSD format (not the current one): http://csd.ihris.org/svn/CSD/queries/exec/fred_conversion.xq

From the public comment version, please note that the facility attributes (which were key-value pairs) have been removed in favor of having a points which allow whatever data model you want. This should, for example, let you capture the hierarchy support in whatever model you land on.