FHIR Oriented RESTful Services

I'm starting to look at how I'd create RESTfully oriented FHIR services.  I'm looking at using the current FHIR DSTU as a collection of Entity Services.  What I want to focus on next are the Task oriented services which use those entities to supply business logic to perform a particular function.

From a service perspective, the key thing about task services is that rather than focusing on what entities exist, they focus on the logic needed to manipulate them to work on a particular function.  An example of this in Healthcare would be the case of Patient Admission.  In this context, you need to gather a number of entities carrying data about the patient, such as their demographics and insurance information, current problems (e.g., chief complaint and/or reason for visit), and create a new encounter associated with that patient entity (which has to be created in a system if it doesn't already exist, or which has to update existing records for the patient if there are any changes), and then associate the chief complaint, reason for visit or admission diagnosis with the encounter.

A task oriented service could call on other task oriented services as well. Admission has a smaller step of patient registration, and so I'd have the admission service call on the registration service first, and if that succeeded, then call on the remainder of the logic to finish the job.

Defining this simply could be a challenge.  I want to be able to support the same level of ease of definition in creating a task service as FHIR already has for its current set of resources.  From the perspective of how this looks over the wire, what I see is that each service has an end-point, from which one or more capabilities are provided (another part of the endpoint).  So, for the Admission Service, I might have an Admit capability and a Register Capability.

http://server.com/service/admission/admit
http://server.com/service/admission/register

Each of these endpoints would have an "API" as it were, a defined set of required and optional inputs, specified similarly to how search parameters are specified in FHIR for the various resources.

Some inputs might be simple types, such as codes, endpoint URLs, and strings.  Others would be resource references, or resources, or compositions, messages, documents or resource feeds.

Simple types and resource references might be specified as URL parameters in making the call.  Full resources might be specified in the request body.  I'm thinking the request would be a POST (or maybe a PUT).  The response would follow usual HTTP patterns, just a 200 OK if everything did what it needed to, but might also include a FHIR Resource or collection (atom) in response to the resource request.

Anyway, that's what I'm thinking about.