I have no idea how to share a google document with a google group in
any kind of fine tuned way. So the world can edit as long as they
have the link That is fine for now.
The important highlights are:
1. definition of a facility registry representation. We didn't have
that before, just examples.
2. ability to represent multiple identifier aliases
3. ability to represent links to additional resources
4. ability for applications to innovate and extend whilst remaining
conformant to the base requirements
We have focussed discussion in the last two weeks on how to represent
a facility. I think we are nearly done with that. There is some
additional discussion we could have about moving some more generic
elements into the facility namespace (eg. address etc). There is a
tension here between prescribing more - which supposedly will increase
interoperability - and prescribing less, which will increase ease of
implementation. As a general approach I lean towards prescribing less
until such a time as we have some good working examples of what works
best. Then we prescribe from a position of strength.
What still needs to be done is bit of a refactor of the service aspect
ie. the definition of REST api endpoints. Hoping much of this will be
copied and pasted from earlier draft (with some edits and removals
along the way). Again I suggest the same principle of prescribing a
minimal core set of services, and allowing application to provide any
number of other rich operations.
Great work all. This is looking good. I like the proposed schema that Bob has put out, it should be simple to implement. I like the idea here of pulling out a core subset of the API and prescribing that. This will allow me to try support a core set of important web services in the Rwandan Health Information Exchange without having to support a larger number of web services that may or may not be used.
That is fine for now.
That is fine for now.