This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Specification Feedback (DSTU 2)"
Jump to navigation
Jump to search
(Created page with "This is the welcome page for feedback from DSTU General Feedback See the FHIR support page... Specific feedback requested:") |
Rene spronk (talk | contribs) |
||
| Line 6: | Line 6: | ||
Specific feedback requested: | Specific feedback requested: | ||
| + | |||
| + | *About '''Section 5.1.7 Merging records''' | ||
| + | **If two Patient records have been linked somehow, then I'd expect a query for one of the Patient.identifiers of one of these Patient resources to return a response as if a query was executed against all of the linked patient records. A link of type '''seealso''' is likely to be another FHIR Server, so we may have to limit this behaviour to records that are linked and available on a single server. This is akin to some of the v2 implementations around linking patient records. The alternative is to burden the client with checking for links and executing multiple queries; to me this is functionality that should be taken care of by the server. [[User:Rene spronk|Rene spronk]] ([[User talk:Rene spronk|talk]]) 10:42, 29 October 2015 (EDT) | ||
Revision as of 14:42, 29 October 2015
This is the welcome page for feedback from DSTU
General Feedback
See the FHIR support page...
Specific feedback requested:
- About Section 5.1.7 Merging records
- If two Patient records have been linked somehow, then I'd expect a query for one of the Patient.identifiers of one of these Patient resources to return a response as if a query was executed against all of the linked patient records. A link of type seealso is likely to be another FHIR Server, so we may have to limit this behaviour to records that are linked and available on a single server. This is akin to some of the v2 implementations around linking patient records. The alternative is to burden the client with checking for links and executing multiple queries; to me this is functionality that should be taken care of by the server. Rene spronk (talk) 10:42, 29 October 2015 (EDT)
