GP Connect - Draft API SPecifications

The latest versions of the draft GP Connect API Specifications are now available on the NHS Developer Network.

Get Record
http://data.developer.nhs.uk/fhir/gpconnect-getrecord-phase3/Chapter.1.About/index.html

Appointments
http://data.developer.nhs.uk/fhir/gpconnect-appointments/Chapter.1.About/index.html

Tasks
http://data.developer.nhs.uk/fhir/gpconnect-tasks/Chapter.1.About/index.html

Interested parties will be invited to participate in review and feedback processes in the near future. In the mean time feel free to leave questions on this forum (as others have already started to do).

The trust I work at, uses TPP for it’s community services. Would we be able to use GPSoc allow us to access our data directly?

Following on from that.
The spec mentions a lookup to determine which supplier holds the active GP medical record. Do we have scenarios where the current GP is using EMIS and the community is using TPP, so the patient record is active on both system? (This will be further complicated if the patient’s GP record has been previsouly on TPP).
Can we avoid a lookup and specify which system to use?

Lastly, I may be reading the document incorrectly but it appears the query to get clinical items is

POST [base]/Patient/$getcarerecord

From experience with NHS Scotlands SCIXML and our (English trust) implementation of FHIR. A number of resources such as Encounters and Appointments can return a lot of data so need filtering and/or support for paging. That would imply a single call would be impractical or have issues, so would calling resources directly be more useful?

(Same would apply to DocumentReference requests for the National Record Locator service - need to be filtered and/or paged responses. We have patients with a lot of clinical documents and scanned notes.)

It has certainly come alive and the profile list looks pretty comprehensive. It would be great to extend this library to cross domain exchanges (acute to GP etc)
Suspect that the response issue might boil down to the nature of the API operations?
We should only be specifying operations that produce the data that is needed, and as these are real time responses what is needed is usually quite succinct. Paging is a nightmare to support as a sender I would have thought, date range parameters might be better.