Updated version of new look specification document

Here is a link to a reformulated version of the facility reg
specification document which Matt and I discussed week before last

https://docs.google.com/document/d/1Xkr5vioqjzyHrgpmKKhWzs8vx1dI9uaQR0ckLFrKI3Y/edit

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 :slight_smile: 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.

Bob

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.

Ryan

···

On Wed, Oct 3, 2012 at 5:47 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Here is a link to a reformulated version of the facility reg

specification document which Matt and I discussed week before last

https://docs.google.com/document/d/1Xkr5vioqjzyHrgpmKKhWzs8vx1dI9uaQR0ckLFrKI3Y/edit

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 :slight_smile: That is fine for now.

The important highlights are:

  1. definition of a facility registry representation. We didn’t have

that before, just examples.

  1. ability to represent multiple identifier aliases

  2. ability to represent links to additional resources

  3. 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.

Bob


Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org