When: 5/2/13 at 11:00 AM EDT
Where: Google Hangout
Participants: Scott Teesdale, Ed Jezierski, Chris Ford, Shaun Grannis, Paul Biondich
Recorded Video: http://youtu.be/QIzivc944V4
Agenda: We outlined the areas of work that folks in the community mentioned as interesting for them in previous calls.
Current Pending Topics: (** Please bring up any others that you wish to add )
We are creating github issues for each, to call for discussions from the group about the topics you find interesting.
A) How to expose metadata for a facility registry (fields, types, constraints, etc)
Why it matters: it would help client applications and systems understand the data available and do more transparent integrations. E.g. Commcare adds a form that lets a facility manager update the status of infrastructure in a facility.
B) How to monitor versioning and track updates (and query previous versions etc)
Why it matters: Keeping track of all or some older versions for a facility, just a variable, or the whole facility dataset as a whole supports analysis of progress and retrospective reporting/auditing.
C) Methods to create links and references to the provider registry (and other registries)
Why it matters: It is important to arrive to an interoperable suite of services where complex interrelationships of data are solved by other methods than glomming and replicating all data into all databases. Provider and facility data have many interlinks.
D) Stream of additions and updates from the facility registry
Why it matters: REST integration patterns include exposing an activity stream from a registry system so that other services and HIMs can conceptually subscribe and trigger business processes based on changes in data. ResourceMap supports this as a RSS feed, and Thoughtworks indicated they were working on something similar in other apps may be worthwhile consolidating the conventions about how to expose actors,verbs and other data in the stream as this may facilitate integrating with e.g. Motech or other suites.
For today's call we did a quick checkpoint with Chris about [D], but most of the discussion was taken by [C].
Here are some bulleted notes:
The linking between registries is important
Shaun reinforced it should be achieved in a way that supports country strategies e.g. impose as little as possible by the way of technical/implementation strategy as possible
We discussed the use of LDAP in provider registries and how that would be supported; and also how to make the referencing not technically coupled with LDAP (i.e. how do we allow registries to use LDAP internally- without creating a leaky abstraction that could show up either as a mandated URI format corresponding to LDAP trees or as a query language syntax)
We showed how ResourceMap currently does linked relationships to other sites within the registry (for named relationships such as “reports to” or “sends lab results to” that are defined by users/data managers).
We shared an idea we had had with Bob J some time ago to have external links as an important field type
We sketched online what information would be needed, debated the containment and arrived to something more or less like this working draft, which still has issues that we need to hash out, but it’s a start:
"facilities": [
{
//...core Properties here...
"identifiers": [
//...identifiers here...
]
"properties": {
//...extended properties here...
}
"links": [
{
name:"Lab Manager",
id:"1234567",
//this would be the ID of the target entity
base:"MOH\TB Program"
//this would be an opaque string identifying the authority for the ID above. See issues below
href:"http:/foo.moh.rw/providers/xyz/1234567"
//href should be optional as not all systems will have an http-based rest URL, and not all hrefs will be based off the identifier above.
}
] |
Issues to be discussed with the draft above:
Do folks like the links being segregated in a links array, instead of interspersed in the properties list? Those on the call seemed to like more the separate array
We don’t know if/what to name the extra metadata that gives context to the identifier. The draft says “base” but it is asymmetrical with our own Facility Registry use of Agency and Context. I think maybe having those two fields may make things at least more uniform. Most people will use agency more than context; to represent the id issuing authority.
Href would be good to have and maybe the field can be auto completed from a mask of a base URL and the ID. Our spec doesn’t care about this but I’m thinking about how we can make resource map point in an easy way to the
Do we want an additional link URL to be included - one for users? not one that has a REST representation of data. I’d like for people to jump to a provider registry page for an employee.
Other topics: