This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions Conformance-uslaborder-receiver This is the narrative for the resource. See also the XML or JSON format. USLabOrder Receiver (Requirements Definition) Published: 2014-12-02 (draft) Published by: HL7 Orders and Observation Workgroup Primary Author: Eric Haas Health eData Inc This profile defines the expected capabilities of the USLabOrder Receiver actor when conforming to the The US Receiver Order Implementation (USLabOrder) . This actor is the recipient/filler of a laboratory test order request and declares conformance to RESTful FHIR and FHIR profiles defined in this guide. The order reference one or more FHIR resources conforming to profiles outlined in the USLabOrder guide. General FHIR Version: 0.8 Supported formats: xml, json REST behavior Mode: Server This conformance resource assumes the USLabOrder Receiver is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabOrder Receiver MUST support querying one or more resources outlined by the USLabOrder Guide . The USLabOrder Receiver MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Receiver MUST implement REST behavior according to the FHIR specification and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query. Security: Implementations must meet the security requirements documented in the USLabOrder Guide assumptions . Summary Resource Search Read Read Version Instance History Resource History Validate Create Update Delete DiagnosticOrder Yes Yes Yes Yes Yes Yes Yes DiagnosticOrder Interactions Name Description   search-type Allows a user to search for existing DiagnosticOrder   read Allows retrieval of a specific known DiagnosticOrder   vread Allows retrieval of a specific version of a DiagnosticOrder   history-instance Allows review of changes to a DiagnosticOrder over time   create Allows defining a new DiagnosticOrder   update Allows editing of an existing DiagnosticOrder. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticOrder (and potentially the retiring of the existing DiagnosticOrder). Servers may also limit who can change particular DiagnosticOrder.   validate Allows a client to verify whether a particular new DiagnosticOrder or revision of an existing DiagnosticOrder would be accepted based on validation and other business rules. Useful for some workflows Search Supported Includes: DiagnosticOrder.subject, DiagnosticOrder.orderer, DiagnosticOrder.supportingInformation, DiagnosticOrder.specimen, DiagnosticOrder.uslabcc REST behavior Mode: Client The following conformance rules assumes the USLabOrder Receiver is the client, in other words, operating in 'Push' RESTful interface. The USLabOrder Receiver MUST support querying one or more resources outlined by the USLabOrder Guide . The USLabOrder Receiver MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Receiver MUST implement REST behavior according to the FHIR specification and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query. Security: Implementations must meet the security requirements documented in the USLabOrder Guide assumptions . Summary Resource Search Read Read Version Instance History Resource History Validate Create Update Delete DiagnosticOrder Yes Yes Yes Yes Yes Yes Yes DiagnosticOrder Interactions Name Description   search-type Allows a user to search for existing DiagnosticOrder   read Allows retrieval of a specific known DiagnosticOrder   vread Allows retrieval of a specific version of a DiagnosticOrder   history-instance Allows review of changes to a DiagnosticOrder over time   create Allows defining a new DiagnosticOrder   update Allows editing of an existing DiagnosticOrder. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticOrder (and potentially the retiring of the existing DiagnosticOrder). Servers may also limit who can change particular DiagnosticOrder.   validate Allows a client to verify whether a particular new DiagnosticOrder or revision of an existing DiagnosticOrder would be accepted based on validation and other business rules. Useful for some workflows Search Supported Includes: DiagnosticOrder.subject, DiagnosticOrder.orderer, DiagnosticOrder.supportingInformation, DiagnosticOrder.specimen, DiagnosticOrder.uslabcc   Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification. © HL7.org 2011+. FHIR DSTU (v0.4.0-4902) generated on Fri, Mar 27, 2015 00:19+1100. Links: What's a DSTU? | Version History | Specification Map | Compare to DSTU1 | | Propose a change