Searching: http://spark.furore.com/fhir/_snapshot?id=f9c6b787-4bfd-43d1-8632-d539f1ecd7b6&start=0
From RowNum: 0
id: f9c6b787-4bfd-43d1-8632-d539f1ecd7b6 (excluded)
start: 0
First Link: http://spark.furore.com/fhir/_snapshot?id=f9c6b787-4bfd-43d1-8632-d539f1ecd7b6&start=0
Last Link: http://spark.furore.com/fhir/_snapshot?id=f9c6b787-4bfd-43d1-8632-d539f1ecd7b6&start=0
Type: Searchset, 19 of 19
Conformance/base/_history/spark1 Modified: 6/30/2017 2:58:24 PM +00:00

Base FHIR Conformance Statement (Full)

This is the base conformance statement for FHIR. It represents a server that provides the full set of functionality defined by FHIR. It is provided to use as a template for system designers to build their own conformance statements from

Mode SERVER
Description All the functionality defined in FHIR
Transaction y
System History y
System Search y
Resource Type Profile Read V-Read Search Update Updates Create Delete History
Account http://hl7.org/fhir/StructureDefinition/Account y y y y y y y y
AllergyIntolerance http://hl7.org/fhir/StructureDefinition/AllergyIntolerance y y y y y y y y
Appointment http://hl7.org/fhir/StructureDefinition/Appointment y y y y y y y y
AppointmentResponse http://hl7.org/fhir/StructureDefinition/AppointmentResponse y y y y y y y y
AuditEvent http://hl7.org/fhir/StructureDefinition/AuditEvent y y y y y y y y
Basic http://hl7.org/fhir/StructureDefinition/Basic y y y y y y y y
Binary http://hl7.org/fhir/StructureDefinition/Binary y y y y y y y y
BodySite http://hl7.org/fhir/StructureDefinition/BodySite y y y y y y y y
Bundle http://hl7.org/fhir/StructureDefinition/Bundle y y y y y y y y
CarePlan http://hl7.org/fhir/StructureDefinition/CarePlan y y y y y y y y
Claim http://hl7.org/fhir/StructureDefinition/Claim y y y y y y y y
ClaimResponse http://hl7.org/fhir/StructureDefinition/ClaimResponse y y y y y y y y
ClinicalImpression http://hl7.org/fhir/StructureDefinition/ClinicalImpression y y y y y y y y
Communication http://hl7.org/fhir/StructureDefinition/Communication y y y y y y y y
CommunicationRequest http://hl7.org/fhir/StructureDefinition/CommunicationRequest y y y y y y y y
Composition http://hl7.org/fhir/StructureDefinition/Composition y y y y y y y y
ConceptMap http://hl7.org/fhir/StructureDefinition/ConceptMap y y y y y y y y
Condition http://hl7.org/fhir/StructureDefinition/Condition y y y y y y y y
Conformance http://hl7.org/fhir/StructureDefinition/Conformance y y y y y y y y
Contract http://hl7.org/fhir/StructureDefinition/Contract y y y y y y y y
Coverage http://hl7.org/fhir/StructureDefinition/Coverage y y y y y y y y
DataElement http://hl7.org/fhir/StructureDefinition/DataElement y y y y y y y y
DetectedIssue http://hl7.org/fhir/StructureDefinition/DetectedIssue y y y y y y y y
Device http://hl7.org/fhir/StructureDefinition/Device y y y y y y y y
DeviceComponent http://hl7.org/fhir/StructureDefinition/DeviceComponent y y y y y y y y
DeviceMetric http://hl7.org/fhir/StructureDefinition/DeviceMetric y y y y y y y y
DeviceUseRequest http://hl7.org/fhir/StructureDefinition/DeviceUseRequest y y y y y y y y
DeviceUseStatement http://hl7.org/fhir/StructureDefinition/DeviceUseStatement y y y y y y y y
DiagnosticOrder http://hl7.org/fhir/StructureDefinition/DiagnosticOrder y y y y y y y y
DiagnosticReport http://hl7.org/fhir/StructureDefinition/DiagnosticReport y y y y y y y y
DocumentManifest http://hl7.org/fhir/StructureDefinition/DocumentManifest y y y y y y y y
DocumentReference http://hl7.org/fhir/StructureDefinition/DocumentReference y y y y y y y y
EligibilityRequest http://hl7.org/fhir/StructureDefinition/EligibilityRequest y y y y y y y y
EligibilityResponse http://hl7.org/fhir/StructureDefinition/EligibilityResponse y y y y y y y y
Encounter http://hl7.org/fhir/StructureDefinition/Encounter y y y y y y y y
EnrollmentRequest http://hl7.org/fhir/StructureDefinition/EnrollmentRequest y y y y y y y y
EnrollmentResponse http://hl7.org/fhir/StructureDefinition/EnrollmentResponse y y y y y y y y
EpisodeOfCare http://hl7.org/fhir/StructureDefinition/EpisodeOfCare y y y y y y y y
ExplanationOfBenefit http://hl7.org/fhir/StructureDefinition/ExplanationOfBenefit y y y y y y y y
FamilyMemberHistory http://hl7.org/fhir/StructureDefinition/FamilyMemberHistory y y y y y y y y
Flag http://hl7.org/fhir/StructureDefinition/Flag y y y y y y y y
Goal http://hl7.org/fhir/StructureDefinition/Goal y y y y y y y y
Group http://hl7.org/fhir/StructureDefinition/Group y y y y y y y y
HealthcareService http://hl7.org/fhir/StructureDefinition/HealthcareService y y y y y y y y
ImagingObjectSelection http://hl7.org/fhir/StructureDefinition/ImagingObjectSelection y y y y y y y y
ImagingStudy http://hl7.org/fhir/StructureDefinition/ImagingStudy y y y y y y y y
Immunization http://hl7.org/fhir/StructureDefinition/Immunization y y y y y y y y
ImmunizationRecommendation http://hl7.org/fhir/StructureDefinition/ImmunizationRecommendation y y y y y y y y
ImplementationGuide http://hl7.org/fhir/StructureDefinition/ImplementationGuide y y y y y y y y
List http://hl7.org/fhir/StructureDefinition/List y y y y y y y y
Location http://hl7.org/fhir/StructureDefinition/Location y y y y y y y y
Media http://hl7.org/fhir/StructureDefinition/Media y y y y y y y y
Medication http://hl7.org/fhir/StructureDefinition/Medication y y y y y y y y
MedicationAdministration http://hl7.org/fhir/StructureDefinition/MedicationAdministration y y y y y y y y
MedicationDispense http://hl7.org/fhir/StructureDefinition/MedicationDispense y y y y y y y y
MedicationOrder http://hl7.org/fhir/StructureDefinition/MedicationOrder y y y y y y y y
MedicationStatement http://hl7.org/fhir/StructureDefinition/MedicationStatement y y y y y y y y
MessageHeader http://hl7.org/fhir/StructureDefinition/MessageHeader y y y y y y y y
NamingSystem http://hl7.org/fhir/StructureDefinition/NamingSystem y y y y y y y y
NutritionOrder http://hl7.org/fhir/StructureDefinition/NutritionOrder y y y y y y y y
Observation http://hl7.org/fhir/StructureDefinition/Observation y y y y y y y y
OperationDefinition http://hl7.org/fhir/StructureDefinition/OperationDefinition y y y y y y y y
OperationOutcome http://hl7.org/fhir/StructureDefinition/OperationOutcome y y y y y y y y
Order http://hl7.org/fhir/StructureDefinition/Order y y y y y y y y
OrderResponse http://hl7.org/fhir/StructureDefinition/OrderResponse y y y y y y y y
Organization http://hl7.org/fhir/StructureDefinition/Organization y y y y y y y y
Patient http://hl7.org/fhir/StructureDefinition/Patient y y y y y y y y
PaymentNotice http://hl7.org/fhir/StructureDefinition/PaymentNotice y y y y y y y y
PaymentReconciliation http://hl7.org/fhir/StructureDefinition/PaymentReconciliation y y y y y y y y
Person http://hl7.org/fhir/StructureDefinition/Person y y y y y y y y
Practitioner http://hl7.org/fhir/StructureDefinition/Practitioner y y y y y y y y
Procedure http://hl7.org/fhir/StructureDefinition/Procedure y y y y y y y y
ProcedureRequest http://hl7.org/fhir/StructureDefinition/ProcedureRequest y y y y y y y y
ProcessRequest http://hl7.org/fhir/StructureDefinition/ProcessRequest y y y y y y y y
ProcessResponse http://hl7.org/fhir/StructureDefinition/ProcessResponse y y y y y y y y
Provenance http://hl7.org/fhir/StructureDefinition/Provenance y y y y y y y y
Questionnaire http://hl7.org/fhir/StructureDefinition/Questionnaire y y y y y y y y
QuestionnaireResponse http://hl7.org/fhir/StructureDefinition/QuestionnaireResponse y y y y y y y y
ReferralRequest http://hl7.org/fhir/StructureDefinition/ReferralRequest y y y y y y y y
RelatedPerson http://hl7.org/fhir/StructureDefinition/RelatedPerson y y y y y y y y
RiskAssessment http://hl7.org/fhir/StructureDefinition/RiskAssessment y y y y y y y y
Schedule http://hl7.org/fhir/StructureDefinition/Schedule y y y y y y y y
SearchParameter http://hl7.org/fhir/StructureDefinition/SearchParameter y y y y y y y y
Slot http://hl7.org/fhir/StructureDefinition/Slot y y y y y y y y
Specimen http://hl7.org/fhir/StructureDefinition/Specimen y y y y y y y y
StructureDefinition http://hl7.org/fhir/StructureDefinition/StructureDefinition y y y y y y y y
Subscription http://hl7.org/fhir/StructureDefinition/Subscription y y y y y y y y
Substance http://hl7.org/fhir/StructureDefinition/Substance y y y y y y y y
SupplyDelivery http://hl7.org/fhir/StructureDefinition/SupplyDelivery y y y y y y y y
SupplyRequest http://hl7.org/fhir/StructureDefinition/SupplyRequest y y y y y y y y
TestScript http://hl7.org/fhir/StructureDefinition/TestScript y y y y y y y y
ValueSet http://hl7.org/fhir/StructureDefinition/ValueSet y y y y y y y y
VisionPrescription http://hl7.org/fhir/StructureDefinition/VisionPrescription y y y y y y y y
Conformance/base2/_history/spark2 Modified: 6/30/2017 2:58:26 PM +00:00

Base FHIR Conformance Statement (Empty)

This is the base conformance statement for FHIR. It represents a server that provides the none of the functionality defined by FHIR. It is provided to use as a template for system designers to build their own conformance statements from. A conformance profile has to contain something, so this contains a read of a Conformance Statement

Mode SERVER
Description An empty conformance statement
Transaction
System History
System Search
Resource Type Profile Read V-Read Search Update Updates Create Delete History
Conformance y
Conformance/conformance-daf-query-requestor/_history/spark3 Modified: 6/30/2017 2:58:26 PM +00:00

DAF Requestor

(Requirements Definition)

Published: 2015-04-02 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the DAF Requestor actor when conforming to the DAF FHIR IG.

General

FHIR Version: 1.0.1 (DSTU2)
Supported formats: JSON or XML

REST behavior

The DAF Requestor SHALL support accessing at least one FHIR resource using the appropriate DAF profile(s) for the resource being accessed. The DAF Requestor SHALL implement REST behavior according to the FHIR specification. The DAF Requestor SHALL support either json or xml resource formats for all DAF interactions.

RESTful Operations Summary

Resource(Profile Name) Search Read Read Version Instance History
DAFPatient SHOULD SHOULD SHOULD SHOULD
DAFAllergyIntolerance SHOULD SHOULD SHOULD SHOULD
DAFDiagnosticOrder SHOULD SHOULD SHOULD SHOULD
DAFDiagnosticReport SHOULD SHOULD SHOULD SHOULD
DAFEncounter SHOULD SHOULD SHOULD SHOULD
DAFFamilyMemberHistory SHOULD SHOULD SHOULD SHOULD
DAFImmunization SHOULD SHOULD SHOULD SHOULD
DAFResults SHOULD SHOULD SHOULD SHOULD
DAFMedication SHOULD SHOULD SHOULD SHOULD
DAFMedicationStatement SHOULD SHOULD SHOULD SHOULD
DAFMedicationAdministration SHOULD SHOULD SHOULD SHOULD
DAFCondition SHOULD SHOULD SHOULD SHOULD
DAFProcedure SHOULD SHOULD SHOULD SHOULD
DAFSmokingStatus SHOULD SHOULD SHOULD SHOULD
DAFVitalSigns SHOULD SHOULD SHOULD SHOULD
DAFList SHOULD SHOULD SHOULD SHOULD


Search Operations Summary

DAF Requestors MAY use the following common parameters as part of queries related to DAF profiles:

DAF Requestors SHOULD use the following common parameters as part of queries related to DAF profiles to avoid repeated queries.

DAF Requestors MAY use the following search contexts defined within the FHIR specification.

DAF Requestors MAY use Modifiers as applicable to the data types of the search parameters to access data. DAF Requestors MAY use any search parameters that are appropriate for querying a particular FHIR resource, however they can only count on the search parameters that are identified as SHALL within the DAF Responder's conformance statement to be used in the execution of the search. For a complete list of search parameters that are available, please refer to DAF Responder's conformance statement and the search parameters supported by the base FHIR resources profiled by DAF.



Security:

Implementations must meet the security requirements documented in the DAF implementation guide.

Conformance/conformance-daf-query-responder/_history/spark4 Modified: 6/30/2017 2:58:26 PM +00:00

DAF Responder

(Requirements Definition)

Published: 2015-04-02

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the DAF Responder actor when conforming to the DAF FHIR IG. The profile includes the complete list of actual profiles, RESTful operations, search parameters supported by DAF Responders. DAF Requestors have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

General

FHIR Version: DSTU2
Supported formats: json and xml

REST behavior

The DAF Responder SHALL support the DAF-Patient resource profile. In addition to the DAFPatient, the DAF Responder SHALL support at least one additional resource profile from the list of DAF profiles. The DAF Responder SHALL implement REST behavior according to the FHIR specification. The DAF Responder SHALL support both json and xml resource formats for all DAF interactions. The DAF Responder SHALL identify the DAF profile(s) supported as part of the FHIR BaseResource.Meta.profile attribute for each instance.

Security:

DAF Responders SHALL meet the security requirements documented in the DAF FHIR IG.

RESTful Operations Summary

Resource(Profile Name) Search Read Read Version Instance History
DAF-Patient SHALL SHALL SHOULD SHOULD
DAF-AllergyIntolerance SHALL SHALL SHOULD SHOULD
DAF-DiagnosticOrder SHALL SHALL SHOULD SHOULD
DAF-DiagnosticReport SHALL SHALL SHOULD SHOULD
DAF-Encounter SHALL SHALL SHOULD SHOULD
DAF-FamilyMemberHistory SHALL SHALL SHOULD SHOULD
DAF-Immunization SHALL SHALL SHOULD SHOULD
DAF-Results SHALL SHALL SHOULD SHOULD
DAF-Medication SHALL SHALL SHOULD SHOULD
DAF-MedicationStatement SHALL SHALL SHOULD SHOULD
DAF-MedicationAdministration SHALL SHALL SHOULD SHOULD
DAF-MedicationOrder SHALL SHALL SHOULD SHOULD
DAF-MedicationDispense SHALL SHALL SHOULD SHOULD
DAF-Condition SHALL SHALL SHOULD SHOULD
DAF-Procedure SHALL SHALL SHOULD SHOULD
DAF-SmokingStatus SHALL SHALL SHOULD SHOULD
DAF-VitalSigns SHALL SHALL SHOULD SHOULD
DAF List SHALL SHALL SHOULD SHOULD


Supported profiles

DAF Responders SHALL support the DAFPatient profile. In addition to the DAFPatient profile, DAF Responders SHALL support at least one more profile (for e.g DAFCondition, DAFMedicationAdministration, DAFResults) from the DAF profiles listed in the DAF implementation guide.

Search Operations Summary

DAF Responders SHALL support the following common parameters as part of queries related to DAF profiles:

DAF Responders SHALL support the following search contexts defined within the FHIRspecification.

DAF Responders SHALL support Modifiers as applicable to the data types of the search parameters. DAF Responders SHALL also support Composite Search Parameters as defined in the FHIR specification.

Resource Name Search and Include Parameters
DAF-Patient
DAF-AllergyIntolerance
DAF-DiagnosticOrder
  • identifier - Search for DiagnosticOrder by identifiers ( token)
  • patient - Search for DiagnosticOrders for a patient ( reference)
  • Chained parameter - patient.identifier
  • orderer - Search based on ordering provider ( reference)
  • Chained parameter - orderer.identifier
  • code - Search based on type of the test ordered ( token)
  • encounter - Search based on encounter resulting in the order ( reference)
  • Chained parameter - encounter.identifier
  • item-date - Search based on order date ( date)
  • Include parameter - DiagnosticOrder.subject
  • Include parameter - DiagnosticOrder.orderer
  • Include parameter - DiagnosticOrder.encounter
DAF-DiagnosticReport
  • identifier - Search for DiagnosticReport by identifiers ( token)
  • patient - Search for DiagnosticReport for a patient ( reference)
  • Chained parameter - patient.identifier
  • date - Search based on DiagnosticReport date ( date)
  • encounter - Search based on encounter resulting in the diagnostic report ( reference)
  • Chained parameter - encounter.identifier
  • performer - Search based on diagnostic report performer ( reference)
  • Chained parameter - performer.identifier
  • result - Search based on results included in the diagnostic report ( reference)
  • Chained parameter - result.code
  • Include parameter - DiagnosticReport.subject
  • Include parameter - DiagnosticReport.performer
  • Include parameter - DiagnosticReport.encounter
  • Include parameter - DiagnosticReport.result
DAF-Encounter
  • identifier - Search for Encounter by identifiers ( token)
  • patient - Search for Encounter for a patient ( reference)
  • Chained parameter - patient.identifier
  • location - Search based on Encounter location ( reference)
  • Chained parameter - location.identifier
  • type - Search based on type of the Encounter ( token)
  • date - Search based on encounter start and end date ( date)
  • location-period - Search based on time period during which the patient was at the location ( date)
  • Include parameter - Encounter.patient
  • Include parameter - Encounter.location
  • $everything - Return all the data recorded as part of the encounter.
DAF-FamilyMemberHistory
  • identifier - Search for FamilyMemberHistory by identifiers ( token)
  • patient - Search for FamilyMemberHistory for a patient ( reference)
  • Chained parameter - patient.identifier
  • relationship - Search based on FamilyMemberHistory Relationship type ( token)
  • code - Search based on the clinical condition of the related person ( token)
  • Include parameter - FamilyMemberHistory.patient
DAF-Immunization
  • identifier - Search for Immunization by identifiers ( token)
  • patient - Search for Immunization for a patient ( reference)
  • Chained parameter - patient.identifier
  • date - Search based on Immunization date ( date)
  • vaccine-code - Search based on vaccine product administered ( token)
  • notgiven - Search based on whether immunization was notgiven ( token)
  • lot-number - Search based on vaccine lot number ( string)
  • requester - Search based on ordering provider ( reference)
  • Chained parameter - requester.identifier
  • Include parameter - Immunization.patient
  • Include parameter - Immunization.performer
  • Include parameter - Immunization.requester
  • Include parameter - Immunization.manufacturer
  • Include parameter - Immunization.reaction.detail
DAF-Results
  • identifier - Search for test by identifiers ( token)
  • patient - Search for test for a patient ( reference)
  • Chained parameter - patient.identifier
  • code - Search based on test code ( token)
  • value-concept - Search for a test with a specific value which is a code ( token)
  • value-quantity - Search for a test with a value which is a quantity ( quantity)
  • code-value[x] - Search for a test with a test name and value ( composite)
  • date - Search based on test obtained date ( date)
  • encounter - Search based on encounter resulting in the result ( reference)
  • Chained parameter - encounter.identifier
  • Include parameter - Observation.subject
  • Include parameter - Observation.encounter
  • Include parameter - Observation.related
  • Reverse Include parameter - Observation.component
DAF-Medication
DAF-MedicationStatement
  • identifier - Search by identifiers ( token)
  • patient - Search for medications for a patient ( reference)
  • Chained parameter - patient.identifier
  • effectivedate - Search for medications by date of administration ( date)
  • medication - Search by medication ( reference)
  • Chained parameter - medication.code
  • Include parameter - MedicationStatement.patient
  • Include parameter - MedicationStatement.medication
DAF-MedicationAdministration
  • identifier - Search by identifiers ( token)
  • patient - Search for medications for a patient ( reference)
  • Chained parameter - patient.identifier
  • effectivetime - Search for medications by date of administration ( date)
  • encounter - Search for medications by encounter ( reference)
  • Chained parameter - encounter.identifier
  • practitioner - Search based on practitioner ( reference)
  • Chained parameter - practitioner.identifier
  • prescription - Search based on prescription ( reference)
  • Chained parameter - prescription.identifier
  • Include parameter - MedicationAdministration.patient
  • Include parameter - MedicationAdministration.practitioner
  • Include parameter - MedicationAdministration.encounter
  • Include parameter - MedicationAdministration.prescription
DAF-MedicationDispense
  • identifier - Search by identifiers ( token)
  • patient - Search for medications for a patient ( reference)
  • Chained parameter - patient.identifier
  • code - Search for medications by based on code ( token)
  • medication - Search for medications dispensed by medication ( reference)
  • Include parameter - MedicationDispense.patient
  • Include parameter - MedicationDispense.medicationReference
DAF-MedicationOrder
  • identifier - Search by identifiers ( token)
  • patient - Search for medication orders for a patient ( reference)
  • Chained parameter - patient.identifier
  • code - Search for medication orders by based on code ( token)
  • medication - Search for medication orders by medication ( reference)
  • Include parameter - MedicationOrder.patient
  • Include parameter - MedicationOrder.medicationReference
  • Include parameter - MedicationOrder.encounter
  • Include parameter - MedicationOrder.prescriber
DAF-Condition
  • identifier - Search for Condition by identifiers ( token)
  • code - Search by Condition code ( token)
  • encounter - Search by encounter ( reference)
  • Chained parameter - encounter.identifier
  • onset - Search by onset Age of the condition ( date)
  • patient - Search for conditions for a patient ( reference)
  • Chained parameter - patient.identifier
  • severity - Search for conditions by severity ( token)
  • Include parameter - Condition.patient
  • Include parameter - Condition.encounter
  • Include parameter - Condition.asserter
DAF-Procedure
  • identifier - Search for Procedure by identifiers ( token)
  • code - Search by Procedure type ( token)
  • date - Search by date when procedure was performed ( date)
  • patient - Search for conditions for a patient ( reference)
  • Chained parameter - patient.identifier
  • encounter - Search by encounter ( reference)
  • Chained parameter - encounter.identifier
  • Include parameter - Procedure.patient
  • Include parameter - Procedure.encounter
  • Include parameter - Procedure.performer
DAF-SmokingStatus
  • identifier - Search for SmokingStatus observation by identifiers ( token)
  • date - Search by period that applies to the smoking status ( date)
  • value-concept - Search by a specific value which is a Code ( token)
  • patient - Search for conditions for a patient ( reference)
  • Chained parameter - patient.identifier
  • Include parameter - Observation.subject
  • Include parameter - Observation.encounter
DAF-VitalSigns
  • identifier - Search for Vital Signs by identifiers ( token)
  • date - Search by measurement date ( date)
  • value-quantity - Search for Vital Signs with a value which is a quantity ( quantity)
  • code - Search based on Vital Signs code ( token)
  • code-value[x] - Search for a Vital Signs with a code and value ( token)
  • patient - Search for Vital Signs for a patient ( reference)
  • Chained parameter - patient.identifier
  • Include parameter - Observation.subject
  • Include parameter - Observation.encounter
DAF List
  • identifier - Search for List by identifiers ( token)
  • code - Search by type of list ( token)
  • date - Search by list preparation date ( date)
  • empty-reason - Search by empty reason code ( token)
  • patient - Search for list by patient ( reference)
  • Chained parameter - patient.identifier
  • Include parameter - List.subject
  • Include parameter - List.item


Conformance/conformance-ehrs-rle/_history/spark5 Modified: 6/30/2017 2:58:26 PM +00:00

Record Lifecycle-conformant Electronic Health Record System

(Requirements Definition)

Published: 2014-12-06 (draft)

Published by: Health Level Seven, Int'l - Electronic Health Record work group

This profile defines the expected capabilities of an Electronic Health Record System when conforming to the EHRS functional model's Record Lifecycle specification.

General

FHIR Version: 0.2
Supported formats: xml, json

REST behavior

Conformant systems must record Provenance records on all Create, Update and Delete actions on any resource other than Provenance or AuditEvent. Conformant systems must record AuditEvent records on all Create, Update and Delete actions as well as all GET operations (read, search, etc.)

Security:

Any security rules??

Summary

Resource Search Read Read Version Instance History Resource History Validate Create Update Delete
Provenance Yes
AuditEvent Yes


Provenance

Interactions

Name Description
  create

Allows defining a new data element. Repositories requiring curation of submitted data elements may require all new data elements to have a status of 'draft'.



AuditEvent

Interactions

Name Description
  create

Allows defining a new data element. Repositories requiring curation of submitted data elements may require all new data elements to have a status of 'draft'.

Conformance/conformance-sdc-de-curator/_history/spark8 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Data Element Curator

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Data Element Curator role when conforming to the S&I Framework's Structured Data Capture FHIR Data Element Exchange implementation guide. This role is responsible for defining and updating data elements stored in a repository.

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The primary focus of the curator is the definition and maintenance of DataElements. However, ValueSets must also be supported to allow definition of coded data elements. Some data elements will choose to maintain value sets as 'contained' resources, meaning the value set exists only in the context of the data element and cannot be referenced or maintained without also updating the data element. However, systems should support value set re-use across data elements. (Version-specific referencing can be used to avoid value sets from changing independent of the referencing Questionnaire.)

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
DataElement ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY
ValueSet ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY


DataElement

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing data elements

  read SHALL

Allows retrieval of a specific known data element

  vread SHALL

Allows retrieval of a specific version of a data element

  history-instance SHALL

Allows review of changes to a data element over time

  create SHALL

Allows defining a new data element. Repositories requiring curation of submitted data elements may require all new data elements to have a status of 'draft'.

  update SHALL

Allows maintaining data elements, such as adding additional mappings, display names, etc. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new data element (and potentially the retiring of the existing data element). Servers may also limit who can change particular data elements.

  validate SHOULD

Allows a client to verify whether a particular new data element or revision of an existing data element would be accepted based on validation and other business rules. Useful for some workflows

  delete MAY

Allows removal of an existing data element. Servers may choose to not support deletions or may limit deletions to data elements meeting certain requirements. E.g. only elements with a status of draft or only elements that have been retired for at least two years, etc.



ValueSet

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing value sets for use in authoring data elements

  read SHALL

Allows retrieval of a specific value set referenced within a data element

  vread SHALL

Allows retrieval of a historical version of a value set as referenced within a data element

  history-instance SHALL

Allows review of changes to a value set over time

  create SHALL

Allows definition of a new value set used by one or more data elements

  update SHALL

Allows existing value sets referenced by one or more data elements to be maintained

  validate SHOULD

Allows verification that a value set is valid prior to submission - useful for some workflows.

  delete MAY

Not all servers will support deletion of value sets. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.

Conformance/conformance-sdc-de-registry/_history/spark9 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Data Element Manager

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Data Element Manager role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for defining maintaining a repository of data elements used in designing forms, profiles and templates in support of SDC use-cases, including the pre-population and auto-population of forms.

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The primary focus of the repository is the definition of DataElements. However, ValueSets must also be supported to allow definition of coded data elements. Some data elements will choose to maintain value sets as 'contained' resources, meaning the value set exists only in the context of the data element and cannot be referenced or maintained without also updating the data element. However, systems should support value set re-use across data elements. (Version-specific referencing can be used to avoid value sets from changing independent of the referencing Questionnaire.)

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
DataElement ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY
ValueSet ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY


DataElement

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing data elements

  read SHALL

Allows retrieval of a specific known data element

  vread SHALL

Allows retrieval of a specific version of a data element

  history-instance SHALL

Allows review of changes to a data element over time

  create SHALL

Allows defining a new data element. Repositories requiring curation of submitted data elements may require all new data elements to have a status of 'draft'.

  update SHALL

Allows maintaining data elements while creating and editing forms. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new data element (and potentially the retiring of the existing data element). Servers may also limit who can change particular data elements.

  validate SHOULD

Allows a client to verify whether a particular new data element or revision of an existing data element would be accepted based on validation and other business rules. Useful for some workflows

  delete MAY

Allows removal of an existing data element. Servers may choose to not support deletions or may limit deletions to data elements meeting certain requirements. E.g. only elements with a status of draft or only elements that have been retired for at least two years, etc.

Search

Supported Includes: DataElement.binding.valueSet

Parameter Conformance Type Definition & Chaining
category SHALL token
code SHALL token
date SHALL date
description SHALL string
identifier SHALL token
name SHALL string
publisher SHALL string
status SHALL token
version SHALL string
meaning SHALL token
objectClass SHALL token
property SHALL token


ValueSet

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing value sets for use in authoring data elements

  read SHALL

Allows retrieval of a specific value set referenced within a data element

  vread SHALL

Allows retrieval of a historical version of a value set as referenced within a data element

  history-instance SHALL

Allows review of changes to a value set over time

  create SHALL

Allows definition of a new value set used by one or more data elements

  update SHALL

Allows existing value sets referenced by one or more data elements to be maintained

  validate SHOULD

Allows verification that a value set is valid prior to submission - useful for some workflows.

  delete MAY

Not all servers will support deletion of value sets. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.

Search

Supported Includes: ValueSet.compose.import

Parameter Conformance Type Definition & Chaining
code SHALL token
date SHALL date
description SHALL string
identifier SHALL token
name SHALL string
publisher SHALL string
reference SHALL string
status SHALL token
system SHALL string
version SHALL string
Conformance/conformance-sdc-form-archiver/_history/spark10 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Form Archiver

(Requirements Definition)

Published: 2015-09-03 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Form Archiver role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for persisting (archiving) completed or partially completed forms ( QuestionnaireResponse resource instances). These instances may be submitted individually or in a bundle together with Provenance information providing details about the completion of the questionnaire response. In some cases Binary or DocumentReference resources might also be submitted to convey source information used in the population of the questionnaire response.<br>The focus of this role is on consuming form instances. Examples might be applications accepting insurance coverage forms, research forms, etc. There is no expectation that submitted form data is subsequently made available for retrieval (at least not in the same format).

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The QuestionnaireResponse may be sent as a single instance or as a FHIR Bundle also containing Provenance resources providing details on the sources of information. A Bundle submission might also include Binary and/or DocumentReference instances referring to the data used to populate the form. A Form Archiver must support persisting, searching and retrieving those resources.

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
QuestionnaireResponse ( Profile) SHALL SHOULD MAY
Binary SHOULD MAY MAY
DocumentReference SHOULD MAY MAY
Provenance SHOULD

General interactions

Name Conformance Description
  transaction SHOULD

Modes:

Allows submission of a QuestionnaireResponse together with Provenance and other supporting resources as a single unit of work.



QuestionnaireResponse

Interactions

Name Conformance Description
  create SHALL

Allows archiving (storing) a completed or partially-completed form

  update SHOULD

Allows updating a previously archived form. (Systems may place rules on who can update forms and under what circumstances).

  delete MAY

Allows removal of an archived form from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove a submitted response and under what circumstances.



Binary

Interactions

Name Conformance Description
  create SHOULD

Allows storage of a binary (generally containing information used in the completion of a QuestionnaireResponse). The data might be in a variety of forms.

  update MAY

Allows updating a previously submitted binary data. (Systems may place rules on who can update binary data and under what circumstances).

  delete MAY

Allows removal of binary data from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove binary data and under what circumstances.



DocumentReference

Interactions

Name Conformance Description
  create SHOULD

Allows storage of a document reference (generally containing information used in the completion of a QuestionnaireResponse).

  update MAY

Allows updating a previously submitted document reference. (Systems may place rules on who can update document references and under what circumstances).

  delete MAY

Allows removal of document references from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove document references and under what circumstances.



Provenance

Interactions

Name Conformance Description
  create SHOULD

Allows submitting a Provenance record associated with a particular QuestionnaireResponse.

Conformance/conformance-sdc-form-designer/_history/spark11 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Form Designer

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Form Designer role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for defining forms ( Questionnaire resource instances) that include references to DataElement resouces which define the meaning of particular questions and can be used to aid in pre-populating and auto-populating forms.

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The Questionnaire resource is used to create and maintain SDC-compliant forms. The DataElement resource is used to look-up existing data elements that can be referenced in forms. Optionally, DataElements can also be created and maintained in conjunction with form editing. This is an optional feature as not all environments will provide support for data element definitions from form authors. The ValueSet resource is used to capture allowed values for questions that are to be answered from a pre-defined list of values. For some forms, some or all of the referenced value sets will be handled as 'contained' resources, meaning the value set exists only in the context of the Questionnaire and cannot be referenced or maintained without also updating the form. However, systems should support value set re-use across questionnaires. (Version-specific referencing can be used to avoid value sets from changing independent of the referencing Questionnaire.)

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
Questionnaire ( Profile) SHALL SHALL SHOULD SHOULD SHALL SHALL MAY
ValueSet ( Profile) SHALL SHALL SHOULD SHOULD SHALL SHALL MAY
DataElement ( Profile) SHALL SHALL SHOULD SHOULD MAY MAY MAY


Questionnaire

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing questionnaires for editing

  read SHALL

Allows retrieval of a specific questionnaire by id

  create SHALL

Allows submission of a new form design

  update SHALL

Allows revision of an existing form design. Note that certain types of updates may necessitate retiring the existing form and defining a new one.

  history-instance SHOULD

Allows review of changes to questionnaire over time

  vread SHOULD

Allows retrieval of a historical version of a questionnaire

  delete MAY

Not all servers will support deletion of forms. Status change to 'retired' will be more typical, though deletion of draft profiles may keep repositories cleaner.

  validate MAY

Allows verification that form is valid prior to submission - useful for some workflows.



ValueSet

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing value sets for use by questions in a form

  read SHALL

Allows retrieval of a specific value set by id

  create SHALL

Allows definition of a new value set used by one or more questions

  update SHALL

Allows existing value sets referenced by a form to be maintained. Note that certain types of updates may necessitate retiring the existing value set and defining a new one.

  history-instance SHOULD

Allows review of changes to a value set over time

  vread SHOULD

Allows retrieval of a historical version of a value set

  delete MAY

Not all servers will support deletion of value sets. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.

  validate MAY

Allows verification that a value set is valid prior to submission - useful for some workflows.



DataElement

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing data elements for re-use in a form design

  read SHALL

Allows retrieval of data elements referenced in an existing form design

  vread SHOULD

Allows viewing of specific versions of a data element if the form references a specific version

  history-instance SHOULD

Allows review of changes to a data element over time

  create MAY

Allows defining new data elements for subsequent re-use while creating and editing forms

  update MAY

Allows maintaining data elements while creating and editing forms. Note that certain types of updates may necessitate retiring the existing data element and defining a new one.

  delete MAY

Allows maintaining data elements while creating and editing forms. Note that not all servers will support deleting data elements.

  validate MAY

Allows maintaining data elements while creating and editing forms - user can check that proposed data element is valid prior to submission

Conformance/conformance-sdc-form-filler/_history/spark12 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Form Filler

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Form Filler role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for retrieving pre-defined forms, requesting pre-population of forms and/or auto-populating forms, guiding the user through verifying populated data and submitting completed or partially-completed forms.

Note that Form Fillers may also take on the role of Form Archiver if they have a requirement to retain the completed version of a form (and potentially the source data that was used to complete it).

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The Questionnaire and ValueSet resources are retrieved to allow the system to guide the user through the entry process. The Binary and DocumentReference resources allow the system to find existing clinical documents that can be within the pre-population process. (Support for retrieval operations on these resources is optional as the relevant CDA or FHIR structures may also be directly generated by the Form Filler itself.) Finally, the QuestionnaireResponse resource is used to record the populated form.

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
Questionnaire ( Profile) SHALL SHOULD MAY MAY
ValueSet ( Profile) SHALL SHOULD MAY
QuestionnaireResponse ( Profile) SHALL SHOULD SHALL SHALL SHALL
DocumentReference SHOULD
Binary SHOULD MAY

Operations: populate MAY



Questionnaire

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing questionnaires to be completed

  read SHOULD

Allows retrieval of a specific questionnaire by id. Allows systems to maintain a 'favorites' list of forms and retrieve them by id.

  history-instance MAY

Allows review of changes made to a questionnaire over time. Of interest to some systems, but probably not most.

  vread MAY

Allows retrieval of a historical version of a questionnaire. Most systems will make use of the current version only.



ValueSet

Interactions

Name Conformance Description
  read SHALL

Allows retrieval of a specific value set by id (as referenced in a Questionnaire)

  vread SHOULD

Allows retrieval of a specific version of a value set (as referenced in a Questionnaire)

  history-instance MAY

Allows review of changes to a value set over time. Of interest to some systems, but probably not most.



QuestionnaireResponse

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing completed or partially-completed forms. Generally used to find partially-completed forms for update.

  create SHALL

Allows recording a completed or partially-completed form

  update SHALL

Allows updating an existing completed or partially-completed form. (Systems may place rules on who can update forms and under what circumstances.)

  delete SHALL

Allows removal of a completed form from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove a completed form and under what circumstances.

  history-instance SHOULD

Allows review of prior versions of an answer set - allows reversion to previously recorded versions

  validate SHOULD

Allows checking an answer set for validity against submission rules without persisting any data



DocumentReference

Interactions

Name Conformance Description
  search-type SHOULD

Allows discovery of existing documents that may be included in a form pre-population request



Binary

Interactions

Name Conformance Description
  read SHOULD

Allows retrieval of a specific binary (as pointed to by a DocumentReference)

  vread MAY

Allows retrieval of a historical version of a binary. In general, the most recent version would be appropriate, but some may prefer to use the specific version referenced by a DocumentReference.

Conformance/conformance-sdc-form-manager/_history/spark13 Modified: 6/30/2017 2:58:26 PM +00:00

SDC Form Manager

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Form Manager role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for maintaining a repository of form definitions and also of performing pre-population of form data.

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

The primary focus of the repository is the definition of Questionnaires. However, ValueSets must also be supported to allow definition of coded data elements. Some data elements will choose to maintain value sets as 'contained' resources, meaning the value set exists only in the context of the data element and cannot be referenced or maintained without also updating the data element. However, systems should support value set re-use across data elements. (Version-specific referencing can be used to avoid value sets from changing independent of the referencing Questionnaire.)

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
Questionnaire ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY
ValueSet ( Profile) SHALL SHALL SHALL SHALL SHALL SHALL MAY

Operations: populate MAY



Questionnaire

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing forms

  read SHALL

Allows retrieval of a specific known form

  vread SHALL

Allows retrieval of a specific version of a form

  history-instance SHALL

Allows review of changes to a form over time

  create SHALL

Allows defining a new form. Repositories requiring curation of submitted forms may require all new data elements to have a status of 'draft'.

  update SHALL

Allows an existing form to be updated. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new questionnaire (and potentially the retiring of the existing questionnaire). Servers may also limit who can change particular forms.

  validate SHOULD

SHOULD. Allows a client to verify whether a particular new form or revision of an existing form would be accepted based on validation and other business rules. Useful for some workflows

  delete MAY

Allows removal of an existing form. Servers may choose to not support deletions and instead require that the form's status be changed to 'retired'. Other systems support deletions but limit them to forms meeting certain requirements. E.g. only forms with a status of draft or only forms that have been retired for at least two years, etc.

Search

Supported Includes: Questionnaire.group.question.options

Parameter Conformance Type Definition & Chaining
code SHALL token
date SHALL date
identifier SHALL token
publisher SHALL string
status SHALL token
title SHALL string
version SHALL string
deReference SHALL token


ValueSet

Interactions

Name Conformance Description
  search-type SHALL

Allows discovery of existing value sets for use in authoring questionnaires

  read SHALL

Allows retrieval of a specific value set referenced within a questionnaire

  vread SHALL

Allows retrieval of a historical version of a value set as referenced within a questionnaire

  history-instance SHALL

Allows review of changes to a value set over time

  create SHALL

Allows definition of a new value set used by one or more questionnaires

  update SHALL

Allows existing value sets referenced by one or more questionnaires to be maintained

  validate SHOULD

Allows verification that a value set is valid prior to submission - useful for some workflows.

  delete MAY

Not all servers will support deletion of value sets. Status change to 'retired' will be more typical, though deletion of draft value sets may keep repositories cleaner.

Search

Supported Includes: ValueSet.compose.import

Parameter Conformance Type Definition & Chaining
code SHALL token
date SHALL date
description SHALL string
identifier SHALL token
name SHALL string
publisher SHALL string
reference SHALL string
status SHALL token
system SHALL string
version SHALL string
Conformance/conformance-sdc-form-receiver/_history/spark14 Modified: 6/30/2017 2:58:27 PM +00:00

SDC Form Receiver

(Requirements Definition)

Published: 2014-07-06 (draft)

Published by: U.S. Office of the National Coordinator (ONC)

This profile defines the expected capabilities of the SDC Form Receiver role when conforming to the S&I Framework's Structured Data Capture FHIR implementation guide. This role is responsible for storing and returning completed and partially-completed forms.

General

FHIR Version: 1.0.1
Supported formats: xml, json

REST behavior

Security:

Implementations must meet the general security requirements documented in the SDC implementation guide.

Resource summary

Resource Search Read Read Version Instance History Resource History Create Update Delete
QuestionnaireResponse ( Profile) SHALL SHALL SHALL SHALL SHALL


QuestionnaireResponse

Interactions

Name Conformance Description
  search-type SHALL

Allows a user to search for existing completed or partially-completed forms. Generally used to find partially-completed forms for update.

  create SHALL

Allows recording a completed or partially-completed form

  update SHALL

Allows updating an existing completed or partially-completed form. (Systems may place rules on who can update forms and under what circumstances.)

  delete SHALL

Allows removal of a completed form from a repository. Note that the removal may be logical rather than physical. Some systems may have rules for who can remove a completed form and under what circumstances.

  history-instance SHALL

Allows review of prior versions of an answer set - allows reversion to previously recorded versions

  validate SHALL

Allows checking an answer set for validity against submission rules without persisting any data

Search

Supported Includes: QuestionnaireResponse.questionnaire Questionnaire.group.question.options

Parameter Conformance Type Definition & Chaining
author SHALL token
authored SHALL date
questionnaire SHALL token
status SHALL token
subject SHALL token
encounter SHOULD token
Conformance/conformance-terminology-server/_history/spark15 Modified: 6/30/2017 2:58:27 PM +00:00

Terminology Service Conformance Statement

Basic conformance statement for a Terminology Server. A server can support more fucntionality than defined here, but this is the minimum amount

Mode SERVER
Description RESTful Terminology Server
Transaction
System History
System Search
Resource Type Profile Read V-Read Search Update Updates Create Delete History
ValueSet StructureDefinition/ValueSet y y
ConceptMap StructureDefinition/ConceptMap y y
Conformance/conformance-uslaborder-orderer/_history/spark16 Modified: 6/30/2017 2:58:27 PM +00:00

USLabOrder Orderer

(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 Orderer actor when conforming to the The US Laboratory Order Implementation (USLabOrder). This actor is the originator of a laboratory test order request to the laboratory (order filler) 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 Orderer is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabOrder Orderer MUST support querying one or more resources outlined by the USLabOrder Guide. The USLabOrder Orderer MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Orderer 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 Orderer is the client, in other words, operating in 'Push' RESTful interface. The USLabOrder Orderer MUST support querying one or more resources outlined by the USLabOrder Guide. The USLabOrder Orderer MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Orderer 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

Conformance/conformance-uslaborder-receiver/_history/spark17 Modified: 6/30/2017 2:58:27 PM +00:00

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

Conformance/conformance-uslabreport-receiver/_history/spark18 Modified: 6/30/2017 2:58:27 PM +00:00

USLabReport Receiver

(Requirements Definition)

Published: 2014-12-02 (draft)

Published by: Published by: HL7 Orders and Observation Workgroup Primary Author: Eric Haas Health eData Inc

This profile defines the expected capabilities of the USLabReport Receiver actor when conforming to the The US Receiver Report Implementation (USLabReport). This actor is the receiver of a laboratory test report 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 USLabReport guide.

General

FHIR Version: 0.8
Supported formats: xml, json

REST behavior

Mode: Server

This conformance resource assumes the USLabReport Receiver is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabReport Receiver MUST support querying one or more resources outlined by the USLabReport Guide. The USLabReport Receiver MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport 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 USLabReport Guide assumptions.

Summary

Resource Search Read Read Version Instance History Resource History Validate Create Update Delete
DiagnosticReport Yes Yes Yes Yes Yes Yes Yes


DiagnosticReport

Interactions

Name Description
  search-type

Allows a user to search for existing DiagnosticReport

  read

Allows retrieval of a specific known DiagnosticReport

  vread

Allows retrieval of a specific version of a DiagnosticReport

  history-instance

Allows review of changes to a DiagnosticReport over time

  create

Allows defining a new DiagnosticReport

  update

Allows editing of an existing DiagnosticReport. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport). Servers may also limit who can change particular DiagnosticReport.

  validate

Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules. Useful for some workflows

Search

Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report

REST behavior

Mode: Server

The following conformance rules assumes the USLabReport Receiver is the client, in other words, operating in 'Push' RESTful interface. The USLabReport Receiver MUST support querying one or more resources outlined by the USLabReport Guide. The USLabReport Receiver MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport 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 USLabReport Guide assumptions.

Summary

Resource Search Read Read Version Instance History Resource History Validate Create Update Delete
DiagnosticReport Yes Yes Yes Yes Yes Yes Yes


DiagnosticReport

Interactions

Name Description
  search-type

Allows a user to search for existing DiagnosticReport

  read

Allows retrieval of a specific known DiagnosticReport

  vread

Allows retrieval of a specific version of a DiagnosticReport

  history-instance

Allows review of changes to a DiagnosticReport over time

  create

Allows defining a new DiagnosticReport

  update

Allows editing of an existing DiagnosticReport. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport). Servers may also limit who can change particular DiagnosticReport.

  validate

Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules. Useful for some workflows

Search

Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report

Conformance/conformance-uslabreport-sender/_history/spark19 Modified: 6/30/2017 2:58:27 PM +00:00

USLabReport Sender

(Requirements Definition)

Published: 2014-12-02 (draft)

Published by: Published by: HL7 Orders and Observation Workgroup Primary Author: Eric Haas Health eData Inc

This profile defines the expected capabilities of the USLabReport Sender actor when conforming to the The US Laboratory Report Implementation (USLabReport). This actor is the source of a laboratory test order report 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 USLabReport guide.

General

FHIR Version: 0.8
Supported formats: xml, json

REST behavior

Mode: Server

This conformance resource assumes the USLabReport Sender is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabReport Sender MUST support querying one or more resources outlined by the USLabReport Guide. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender 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 USLabReport Guide assumptions.

Summary

Resource Search Read Read Version Instance History Resource History Validate Create Update Delete
DiagnosticReport Yes Yes Yes Yes Yes Yes Yes


DiagnosticReport

Interactions

Name Description
  search-type

Allows a user to search for existing DiagnosticReport

  read

Allows retrieval of a specific known DiagnosticReport

  vread

Allows retrieval of a specific version of a DiagnosticReport

  history-instance

Allows review of changes to a DiagnosticReport over time

  create

Allows defining a new DiagnosticReport

  update

Allows editing of an existing DiagnosticReport. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport). Servers may also limit who can change particular DiagnosticReport.

  validate

Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules. Useful for some workflows

Search

Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report

REST behavior

Mode: Client

The following conformance rules assumes the USLabReport Sender is the client, in other words, operating in 'Push' RESTful interface. The USLabReport Sender MUST support querying one or more resources outlined by the USLabReport Guide. The USLabReport Sender MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabReport. The USLabReport Sender 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 USLabReport Guide assumptions.

Summary

Resource Search Read Read Version Instance History Resource History Validate Create Update Delete
DiagnosticReport Yes Yes Yes Yes Yes Yes Yes


DiagnosticReport

Interactions

Name Description
  search-type

Allows a user to search for existing DiagnosticReport

  read

Allows retrieval of a specific known DiagnosticReport

  vread

Allows retrieval of a specific version of a DiagnosticReport

  history-instance

Allows review of changes to a DiagnosticReport over time

  create

Allows defining a new DiagnosticReport

  update

Allows editing of an existing DiagnosticReport. Servers may choose to prohibit certain types of edits, instead requiring the creation of a new DiagnosticReport (and potentially the retiring of the existing DiagnosticReport). Servers may also limit who can change particular DiagnosticReport.

  validate

Allows a client to verify whether a particular new DiagnosticReport or revision of an existing DiagnosticReport would be accepted based on validation and other business rules. Useful for some workflows

Search

Supported Includes: DiagnosticReport.subject, DiagnosticReport.performer, DiagnosticReport.request, DiagnosticReport.specimen, DiagnosticReport.report

Conformance/example/_history/spark6 Modified: 6/30/2017 2:58:26 PM +00:00

The EHR Server supports the following transactions for the resource Person: read, vread, update, history, search(name,gender), create and updates.

The EHR System supports the following message: admin-notify::Person.

The EHR Application has a general document profile.

Conformance/phr/_history/spark7 Modified: 6/30/2017 2:58:26 PM +00:00

Prototype Conformance Statement for September 2013 Connectathon

The server offers read and search support on the following resource types: