FHIR © HL7.org  |  Server Home  |  Health Intersections FHIR Server v1.0.262  |  FHIR Version 3.5.0  | User: ANONYMOUS (Unknown)  

History Record

XML or JSON representation

Links: First Previous Next Last  (54 found). Search: http://test.fhir.org/r4/OperationDefinition/_history?&_prior=2018-10-20T18:03:53.499Z&_format=text/xhtml&history-id=9e05ecdb-49d7-4b13-adff-8ddb16e65a 

OperationDefinition "docref" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

OPERATION: US Core Fetch Patient DocumentReferences

This operation is used to return all the references to documents related to a patient.

The operation takes the input parameters:

  • patient id
  • start date
  • end date
  • document type

and returns a Bundle off type “searchset” containing resources conforming to the US Core DocumentReference Profile for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.

The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (GET [base]/DocumentReference?patient=[id]). This operaton differs from a simple query in that DocumentReferences may be created ‘on-the-fly’ in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an ‘on-demand’ document cannot be created then the operation will return an empty search bundle.

URL: [base]/DocumentReference/$docref

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient1..1id

The patient id to match against a patient resource. If there is no match, an empty Bundle is returned

INstart0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INend0..1date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.

INtype0..1CodeableConceptDocument Type Value Set (Required)

The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.

OUTreturn1..1Bundle

The bundle type is "searchset"containing resources conforming to the US Core DocumentReference Profile

  • The server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). This frees the client from needing to determine what it could or should ask for.

  • The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository.

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification


{
  "resourceType" : "OperationDefinition",
  "id" : "docref",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:55:42.109Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n<p>OPERATION: US Core Fetch Patient DocumentReferences</p>\n<p>This operation is used to return all the references to documents related to a patient.</p>\n<p>The operation takes the input parameters:</p>\n<ul>\n<li>patient id</li>\n<li>start date</li>\n<li>end date</li>\n<li>document type</li>\n</ul>\n<p>and returns a <a href=\"http://hl7.org/fhir/bundle.html\">Bundle</a> off type &#8220;searchset&#8221; containing resources conforming to the <a href=\"StructureDefinition-us-core-documentreference.html\">US Core DocumentReference Profile</a> for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information.</p>\n<p>The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (<code>GET [base]/DocumentReference?patient=[id]</code>). This operaton differs from a simple query in that DocumentReferences may be created &#8216;on-the-fly&#8217; in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an &#8216;on-demand&#8217; document cannot be created then the operation will return an empty search bundle.</p>\n<p><code>URL: [base]/DocumentReference/$docref</code></p>\n<p>Parameters</p>\n <!-- table -->\n<table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>patient</td><td>1..1</td><td>id</td><td/><td><div><p>The patient id to match against a patient resource. If there is no match, an empty Bundle is returned</p>\n</div></td></tr><tr><td>IN</td><td>start</td><td>0..1</td><td>date</td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p>\n</div></td></tr><tr><td>IN</td><td>end</td><td>0..1</td><td>date</td><td/><td><div><p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.</p>\n</div></td></tr><tr><td>IN</td><td>type</td><td>0..1</td><td>CodeableConcept</td><td><a href=\"http://hl7.org/fhir/ValueSet/c80-doc-typecodes\">Document Type Value Set</a> (Required)</td><td><div><p>The type relates to document type e.g. the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document if available SHALL be in scope and all other document types MAY be in scope.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td>Bundle</td><td/><td><div><p>The bundle type is \"searchset\"containing resources conforming to the US Core DocumentReference Profile</p>\n</div></td></tr></table>\n<ul>\n<li><p>The server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). This frees the client from needing to determine what it could or should ask for.</p></li>\n<li><p>The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a <a href=\"http://hl7.org/fhir/binary.html\">Binary</a> Resource or some other document repository.</p></li>\n</ul>\n<p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification</p>\n\n&#9;&#9;</div>"
  },
  "url" : "http://hl7.org/fhir/us/core-r4/OperationDefinition/docref",
  "version" : "2.0.0",
  "name" : "US Core Fetch DocumentReferences",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2016-10-18",
  "publisher" : "US Core Project",
  "description" : "This operation is used to return all the references to documents related to a patient. The operation takes the input parameters: - patient id - start date - end date - document type and returns a [Bundle](http://hl7.org/fhir/bundle.html) of type \"searchset\" containing [US Core DocumentReference Profiles](http://hl7.org/fhir/us/core-r4/StructureDefinition-us-core-documentreference.html) for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference profiles needed to support the records. The principle intended use for this operation is to provide a provider or patient with access to their available document information. The server SHOULD return at least all references for documents that it has made available in a document indexing system. This is the same as a simple query (`GET [base]/DocumentReference?patient=[id]`). This operaton differs from a simple query in that DocumentReferences may be created 'on-the-fly' in response to this operation. For example, in some cases the documents themselves may not exist but can be generated when needed so a reference to them can be generated using this operation. If no documents exist and an 'on-demand' document cannot be created then the operation will return an empty search bundle.",
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "urn:iso:std:iso:3166",
          "code" : "US",
          "display" : "United States of America"
        }
      ]
    }
  ],
  "code" : "docref",
  "comment" : " - The server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). This frees the client from needing to determine what it could or should ask for. - The document itself can be subsequently retrieved using the link provided from the DocumentQuery search results. The link could,for example, be a FHIR endpoint to a Binary Resource or some other document repository. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification",
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "patient",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The id of the patient resource located on the server on which this operation is executed. If there is no match, an empty Bundle is returned",
      "type" : "id"
    },
    {
      "name" : "start",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all documents prior to the end date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope.",
      "type" : "date"
    },
    {
      "name" : "end",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all documents subsequent to the start date are in scope. If neither a start date nor an end date is provided, the most recent or current document is in scope",
      "type" : "date"
    },
    {
      "name" : "type",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The type relates to document type e.g. for the LOINC code for a C-CDA Clinical Summary of Care (CCD) is 34133-9 (Summary of episode note). If no type is provided, the CCD document, if available, SHALL be in scope and all other document types MAY be in scope",
      "type" : "CodeableConcept",
      "binding" : {
        "strength" : "required"
      }
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"containing Argonaut DocumentReference Profiles",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Questionnaire-process-response" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Questionnaire Process Response

OPERATION: Questionnaire Process Response

The official URL for this operation definition is:

http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-process-response

This operation allows a system to 'receive' a QuestionnaireResponse for a particular Questionnaire. It is intended to be used by systems that expect to receive completed questionnaires but which don't necessarily want to host a RESTful endpoint where those responses are subsequently queryable. The receiver may choose to perform validation of the received response or against local business rules. There no response beyond an HTTP 200 OK if the response is consumed successfully, though an OperationOutcome can optionally be returned identifying warnings. If there are validation or other issues, the operation will fail with details in an OperationOutcome. The specific action that occurs on receipt of a form will depend on both the type of form and the submitter. It could trigger admission to a clinical trial, the beginning of an product investigation, the consideration of a patient's eligibility for coverage, etc. Alternatively, the data may simply be consumed and aggregated with other information for analysis or other use.

URL: [base]/Questionnaire/$process-response

URL: [base]/Questionnaire/[id]/$process-response

Parameters

UseNameCardinalityTypeBindingDocumentation
INresponse1..1QuestionnaireResponse

The questionnaire response to be accepted/processed

OUTwarnings0..1OperationOutcome

If the response is successfully procssed, an OperationOutcome may still be returned indicating warnings. For example, identifying questions that were incomplete, answers that were defaulted, etc. It may also convey 'information' messages about the processing of the questionnaire response.

Some receivers may accept responses that are still 'in progress', but others may reject instances with a status other than 'final' or possibly 'amended'. If the operation is invoked on a particular Questionnaire, the submitted QuestionnaireResponse must be a response to the specified Questionnaire. Otherwise, the QuestionnaireResponse will be validated against whatever Questionnaire the QuestionnaireResponse references. It is an error for a QuestionnaireResponse that does not declare a questionnaire to be invoked directly on the Questionnaire endpoint.


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-process-response",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:54:35.671Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>Questionnaire Process Response</h2><p>OPERATION: Questionnaire Process Response</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-process-response</pre><div><p>This operation allows a system to 'receive' a QuestionnaireResponse for a particular Questionnaire. It is intended to be used by systems that expect to receive completed questionnaires but which don't necessarily want to host a RESTful endpoint where those responses are subsequently queryable. The receiver may choose to perform validation of the received response or against local business rules. There no response beyond an HTTP 200 OK if the response is consumed successfully, though an OperationOutcome can optionally be returned identifying warnings. If there are validation or other issues, the operation will fail with details in an OperationOutcome. The specific action that occurs on receipt of a form will depend on both the type of form and the submitter. It could trigger admission to a clinical trial, the beginning of an product investigation, the consideration of a patient's eligibility for coverage, etc. Alternatively, the data may simply be consumed and aggregated with other information for analysis or other use.</p>\n</div><p>URL: [base]/Questionnaire/$process-response</p><p>URL: [base]/Questionnaire/[id]/$process-response</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>response</td><td>1..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/questionnaireresponse.html\">QuestionnaireResponse</a></td><td/><td><div><p>The questionnaire response to be accepted/processed</p>\n</div></td></tr><tr><td>OUT</td><td>warnings</td><td>0..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/operationoutcome.html\">OperationOutcome</a></td><td/><td><div><p>If the response is successfully procssed, an OperationOutcome may still be returned indicating warnings. For example, identifying questions that were incomplete, answers that were defaulted, etc. It may also convey 'information' messages about the processing of the questionnaire response.</p>\n</div></td></tr></table><div><p>Some receivers may accept responses that are still 'in progress', but others may reject instances with a status other than 'final' or possibly 'amended'. If the operation is invoked on a particular Questionnaire, the submitted QuestionnaireResponse must be a response to the specified Questionnaire. Otherwise, the QuestionnaireResponse will be validated against whatever Questionnaire the QuestionnaireResponse references. It is an error for a QuestionnaireResponse that does not declare a questionnaire to be invoked directly on the Questionnaire endpoint.</p>\n</div></div>"
  },
  "url" : "http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-process-response",
  "version" : "current",
  "name" : "Questionnaire Process Response",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2017-03-19",
  "publisher" : "Health Level Seven",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "other",
          "value" : "http://hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation allows a system to 'receive' a QuestionnaireResponse for a particular Questionnaire. It is intended to be used by systems that expect to receive completed questionnaires but which don't necessarily want to host a RESTful endpoint where those responses are subsequently queryable. The receiver may choose to perform validation of the received response or against local business rules. There no response beyond an HTTP 200 OK if the response is consumed successfully, though an OperationOutcome can optionally be returned identifying warnings. If there are validation or other issues, the operation will fail with details in an OperationOutcome. The specific action that occurs on receipt of a form will depend on both the type of form and the submitter. It could trigger admission to a clinical trial, the beginning of an product investigation, the consideration of a patient's eligibility for coverage, etc. Alternatively, the data may simply be consumed and aggregated with other information for analysis or other use.",
  "code" : "process-response",
  "comment" : "Some receivers may accept responses that are still 'in progress', but others may reject instances with a status other than 'final' or possibly 'amended'. If the operation is invoked on a particular Questionnaire, the submitted QuestionnaireResponse must be a response to the specified Questionnaire. Otherwise, the QuestionnaireResponse will be validated against whatever Questionnaire the QuestionnaireResponse references. It is an error for a QuestionnaireResponse that does not declare a questionnaire to be invoked directly on the Questionnaire endpoint.",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "response",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The questionnaire response to be accepted/processed",
      "type" : "QuestionnaireResponse",
      "targetProfile" : [
        "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponse"
      ]
    },
    {
      "name" : "warnings",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "If the response is successfully procssed, an OperationOutcome may still be returned indicating warnings. For example, identifying questions that were incomplete, answers that were defaulted, etc. It may also convey 'information' messages about the processing of the questionnaire response.",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "Questionnaire-next-question" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

NextQuestion

OPERATION: NextQuestion

The official URL for this operation definition is:

http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-next-question

The Next Question operation is used for adaptive questionnaires - forms where the next question (or set of questions) is based on previous answers. The result of this operation is to return an updated QuestionnaireResponse with a contained Questionnaire that includes the next question (or set of questions). It might also include display items with instructions and/or read-only questions containing calculated scores. This operation uses the QuestionnaireResponse resource with a contained Questionnaire as both the input and output parameter. The client initiates and queries for the next question by including the answers to all required questions in the questionnaire to that point. The Server updates the contained Questionnaire in the QuestionnaireResponse in the with the next question or set of questions and any needed instruction or score items. When the questionnaire is complete, the Server updates the QuestionnaireResponse.status resource parameter to complete. If completion of the questionnaire has exceeded any time limit, the Server may return an OperationOutcome with an error.

URL: [base]/Questionnaire/$next-question

Parameters

UseNameCardinalityTypeBindingDocumentation
INquestionnaire-response1..1Resource

The Adaptive QuestionnaireResponse Profile of the QuestionnaireResponse resource with a contained Questionnaire. When invoking the operation for the first time, neither the QuestionnaireResponse nor the contained Questionnaire will have any items, as no questions are yet known. In subsequent calls, the QuestionnaireResponse will include answers to all required questions asked so far and the contained QuestionnaireResponse will remain the same as provided back from the operation in the preceding response.

OUTreturn1..1Resource

The Adaptive QuestionnaireResponse Profile of the QuestionnaireResponse resource with a contained Questionnaire. The Server updates the QuestionnaireResponse's contained Questionnaire by appending with the next question or questions ittems and any score or instruction items and returns the QuestionnaireResponse (with all answers completed thus far plus any calculated scores) as this parameter. When the questionnaire is complete, the Server updates the status of the QuestionnaireResponse resource parameter to complete.

To return a calculated score for the questionnaire or group of items, the service may return a readOnly question with the score value in the corresponding QuestionnaireResponse.item. The extension questionnaire-hidden can be included on the Questionnaire.item to indicate to the client that it should not be displayed to the end user


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-next-question",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:54:35.624Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>NextQuestion</h2><p>OPERATION: NextQuestion</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-next-question</pre><div><p>The Next Question operation is used for <em>adaptive questionnaires</em> - forms where the next question (or set of questions) is based on previous answers. The result of this operation is to return an updated QuestionnaireResponse with a contained Questionnaire that includes the next question (or set of questions). It might also include display items with instructions and/or read-only questions containing calculated scores. This operation uses the <a href=\"http://hl7.org/fhir/STU3/questionnaireresponse.html\">QuestionnaireResponse</a> resource with a <a href=\"http://hl7.org/fhir/STU3/references.html#contained\"><em>contained</em></a> <a href=\"http://hl7.org/fhir/STU3/questionnaire.html\">Questionnaire</a> as both the input and output parameter. The client initiates and queries for the next question by including the answers to all required questions in the questionnaire to that point. The Server updates the contained Questionnaire in the QuestionnaireResponse in the with the next question or set of questions and any needed instruction or score items. When the questionnaire is complete, the Server updates the <code>QuestionnaireResponse.status</code> resource parameter to <code>complete</code>. If completion of the questionnaire has exceeded any time limit, the Server may return an <a href=\"http://hl7.org/fhir/STU3/operationoutcome.html\">OperationOutcome</a> with an error.</p>\n</div><p>URL: [base]/Questionnaire/$next-question</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>questionnaire-response</td><td>1..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/resource.html\">Resource</a></td><td/><td><div><p>The <a href=\"sdc-questionnaireresponse-adapt.html\">Adaptive QuestionnaireResponse Profile</a> of the QuestionnaireResponse resource with a <em>contained</em> Questionnaire. When invoking the operation for the first time, neither the QuestionnaireResponse nor the contained Questionnaire will have any items, as no questions are yet known. In subsequent calls, the QuestionnaireResponse will include answers to all required questions asked so far and the contained QuestionnaireResponse will remain the same as provided back from the operation in the preceding response.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/resource.html\">Resource</a></td><td/><td><div><p>The <a href=\"sdc-questionnaireresponse-adapt.html\">Adaptive QuestionnaireResponse Profile</a> of the QuestionnaireResponse resource with a <em>contained</em> Questionnaire. The Server updates the QuestionnaireResponse's contained Questionnaire by appending with the next question or questions ittems and any score or instruction items and returns the QuestionnaireResponse (with all answers completed thus far plus any calculated scores) as this parameter. When the questionnaire is complete, the Server updates the status of the QuestionnaireResponse resource parameter to <code>complete</code>.</p>\n</div></td></tr></table><div><p>To return a calculated score for the questionnaire or group of items, the service may return a <code>readOnly</code> question with the score value in the corresponding QuestionnaireResponse.item. The extension <code>questionnaire-hidden</code> can be included on the Questionnaire.item to indicate to the client that it should not be displayed to the end user</p>\n</div></div>"
  },
  "url" : "http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-next-question",
  "version" : "current",
  "name" : "NextQuestion",
  "title" : "Adaptive Questionnaire - Next Question Operation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-29",
  "publisher" : "HL7 International - FHIR Infrastructure",
  "description" : "The Next Question operation is used for *adaptive questionnaires* - forms where the next question (or set of questions) is based on previous answers. The result of this operation is to return an updated QuestionnaireResponse with a contained Questionnaire that includes the next question (or set of questions). It might also include display items with instructions and/or read-only questions containing calculated scores. This operation uses the [QuestionnaireResponse](http://hl7.org/fhir/STU3/questionnaireresponse.html) resource with a [*contained*](http://hl7.org/fhir/STU3/references.html#contained) [Questionnaire](http://hl7.org/fhir/STU3/questionnaire.html) as both the input and output parameter. The client initiates and queries for the next question by including the answers to all required questions in the questionnaire to that point. The Server updates the contained Questionnaire in the QuestionnaireResponse in the with the next question or set of questions and any needed instruction or score items. When the questionnaire is complete, the Server updates the `QuestionnaireResponse.status` resource parameter to `complete`. If completion of the questionnaire has exceeded any time limit, the Server may return an [OperationOutcome](http://hl7.org/fhir/STU3/operationoutcome.html) with an error.",
  "code" : "next-question",
  "comment" : "To return a calculated score for the questionnaire or group of items, the service may return a `readOnly` question with the score value in the corresponding QuestionnaireResponse.item. The extension `questionnaire-hidden` can be included on the Questionnaire.item to indicate to the client that it should not be displayed to the end user",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "questionnaire-response",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The [Adaptive QuestionnaireResponse Profile](sdc-questionnaireresponse-adapt.html) of the QuestionnaireResponse resource with a *contained* Questionnaire. When invoking the operation for the first time, neither the QuestionnaireResponse nor the contained Questionnaire will have any items, as no questions are yet known. In subsequent calls, the QuestionnaireResponse will include answers to all required questions asked so far and the contained QuestionnaireResponse will remain the same as provided back from the operation in the preceding response.",
      "type" : "Resource",
      "targetProfile" : [
        "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-adapt"
      ]
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The [Adaptive QuestionnaireResponse Profile](sdc-questionnaireresponse-adapt.html) of the QuestionnaireResponse resource with a *contained* Questionnaire. The Server updates the QuestionnaireResponse's contained Questionnaire by appending with the next question or questions ittems and any score or instruction items and returns the QuestionnaireResponse (with all answers completed thus far plus any calculated scores) as this parameter. When the questionnaire is complete, the Server updates the status of the QuestionnaireResponse resource parameter to `complete`.",
      "type" : "Resource",
      "targetProfile" : [
        "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponse-adapt"
      ]
    }
  ]
}

OperationDefinition "Questionnaire-extract" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

QuestionnaireExtract

OPERATION: QuestionnaireExtract

The official URL for this operation definition is:

http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-extract

The Extract operation takes a completed QuestionnaireRespponse and converts it to a FHIR resource or Bundle of resources by using metadata embedded in the Questionnaire the Questionnaire is based on or that the operation is invoked on. The extracted resources might include Observations, MedicationStatements and other standard FHIR resources which can then be shared and manipulated.

URL: [base]/Questionnaire/$extract

URL: [base]/Questionnaire/[id]/$extract

Parameters

UseNameCardinalityTypeBindingDocumentation
INquestionnaire-response1..1Resource

The QuestionnaireResponse to extract data from. The QuestionnaireResponse must either reference a Questionnaire that complies with a the Questionnaire Extract Profile or the operation must be invoked on a Questionnaire that complies with the profile. This is necessary to ensure appropriate metadata is available to support extraction.

OUTreturn1..1Resource

The resulting FHIR resource produced after extracting data. This might be a single clinical administrative resource or could be a Transaction Bundle that contains multiple resources.

If the operation is invoked on a Questionnaire instance rather than the Questionnaire type, the instance SHALL either have the same canonical URL as the QuestionnaireResponse.questionnaire element or must have a Questionnaire.derivedFrom element with that canonical URL.


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-extract",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:54:35.577Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>QuestionnaireExtract</h2><p>OPERATION: QuestionnaireExtract</p><p>The official URL for this operation definition is: </p><pre>http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-extract</pre><div><p>The Extract operation takes a completed QuestionnaireRespponse and converts it to a FHIR resource or Bundle of resources by using metadata embedded in the Questionnaire the Questionnaire is based on or that the operation is invoked on. The extracted resources might include Observations, MedicationStatements and other standard FHIR resources which can then be shared and manipulated.</p>\n</div><p>URL: [base]/Questionnaire/$extract</p><p>URL: [base]/Questionnaire/[id]/$extract</p><p>Parameters</p><table class=\"grid\"><tr><td><b>Use</b></td><td><b>Name</b></td><td><b>Cardinality</b></td><td><b>Type</b></td><td><b>Binding</b></td><td><b>Documentation</b></td></tr><tr><td>IN</td><td>questionnaire-response</td><td>1..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/resource.html\">Resource</a></td><td/><td><div><p>The QuestionnaireResponse to extract data from. The QuestionnaireResponse must either reference a Questionnaire that complies with a the <a href=\"sdc-questionnaire-extract.html\">Questionnaire Extract Profile</a> or the operation must be invoked on a Questionnaire that complies with the profile. This is necessary to ensure appropriate metadata is available to support extraction.</p>\n</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td><a href=\"http://hl7.org/fhir/2018Sep/resource.html\">Resource</a></td><td/><td><div><p>The resulting FHIR resource produced after extracting data. This might be a single clinical administrative resource or could be a Transaction Bundle that contains multiple resources.</p>\n</div></td></tr></table><div><p>If the operation is invoked on a Questionnaire instance rather than the Questionnaire type, the instance SHALL either have the same canonical URL as the <code>QuestionnaireResponse.questionnaire</code> element or must have a <code>Questionnaire.derivedFrom</code> element with that canonical URL.</p>\n</div></div>"
  },
  "url" : "http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-extract",
  "version" : "current",
  "name" : "QuestionnaireExtract",
  "title" : "Questionnaire response extract to resource(s)",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-30",
  "publisher" : "HL7 International - FHIR Infrastructure",
  "description" : "The Extract operation takes a completed QuestionnaireRespponse and converts it to a FHIR resource or Bundle of resources by using metadata embedded in the Questionnaire the Questionnaire is based on or that the operation is invoked on. The extracted resources might include Observations, MedicationStatements and other standard FHIR resources which can then be shared and manipulated.",
  "code" : "extract",
  "comment" : "If the operation is invoked on a Questionnaire instance rather than the Questionnaire type, the instance SHALL either have the same canonical URL as the `QuestionnaireResponse.questionnaire` element or must have a `Questionnaire.derivedFrom` element with that canonical URL.",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "questionnaire-response",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The QuestionnaireResponse to extract data from. The QuestionnaireResponse must either reference a Questionnaire that complies with a the [Questionnaire Extract Profile](sdc-questionnaire-extract.html) or the operation must be invoked on a Questionnaire that complies with the profile. This is necessary to ensure appropriate metadata is available to support extraction.",
      "type" : "Resource",
      "targetProfile" : [
        "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaireresponse"
      ]
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resulting FHIR resource produced after extracting data. This might be a single clinical administrative resource or could be a Transaction Bundle that contains multiple resources.",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "ValueSet-validate-code" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Value Set based Validation

OPERATION: Value Set based Validation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code

Validate that a coded value is in the set of codes allowed by a value set.

If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code

URL: [base]/ValueSet/$validate-code

URL: [base]/ValueSet/[id]/$validate-code

Parameters

Use Name Cardinality Type Binding Documentation
IN url 0..1 uri

Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server

IN valueSetVersion 0..1 string

The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.

IN code 0..1 code

The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)

IN system 0..1 uri

The system for the code that is to be validated

IN systemVersion 0..1 string

The version of the system, if one was provided in the source data

IN display 0..1 string

The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent

IN coding 0..1 Coding

A coding to validate

IN codeableConcept 0..1 CodeableConcept

A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present

IN date 0..1 dateTime

The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN abstract 0..1 boolean

If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is fase, abstract codes are not considered to be valid.

Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in a actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.

IN displayLanguage 0..1 code

Specifies the language to be used for description when validating the display property

OUT result 1..1 boolean

True if the concept details supplied are valid

OUT message 0..1 string

Error details, if result = false. If this is provided when result = true, the message carries hints and warnings

OUT display 0..1 string

A valid display for the concept if the system wishes to display this to a user

Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-validate-code",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.890Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Value Set based Validation</h2>\n <p>OPERATION: Value Set based Validation</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code</pre>\n <div>\n <p>Validate that a coded value is in the set of codes allowed by a value set.</p>\n\n <p>If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code</p>\n\n </div>\n <p>URL: [base]/ValueSet/$validate-code</p>\n <p>URL: [base]/ValueSet/[id]/$validate-code</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>context</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSet</td>\n <td>0..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSetVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>code</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The system for the code that is to be validated</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>systemVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The version of the system, if one was provided in the source data</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>display</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>coding</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A coding to validate</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>codeableConcept</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>date</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>abstract</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is fase, abstract codes are not considered to be valid.</p>\n\n <p>Note that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in a actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>displayLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies the language to be used for description when validating the display property</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>True if the concept details supplied are valid</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>message</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Error details, if result = false. If this is provided when result = true, the message carries hints and warnings</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>display</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A valid display for the concept if the system wishes to display this to a user</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Normative"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code",
  "name" : "Value Set based Validation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Validate that a coded value is in the set of codes allowed by a value set.\n\nIf the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. One (and only one) of the in parameters code, coding, or codeableConcept must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code",
  "code" : "validate-code",
  "comment" : "Note: the correct behaviour of validation with regard to language for Coding.display items is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases",
  "resource" : [
    "ValueSet"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Value set Canonical URL. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server",
      "type" : "uri"
    },
    {
      "name" : "context",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The context of the value set, so that the server can resolve this to a value set to validate against. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time",
      "type" : "uri"
    },
    {
      "name" : "valueSet",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion. This parameter is used when the client wants the server to expand a value set that is not stored on the server",
      "type" : "ValueSet"
    },
    {
      "name" : "valueSetVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The identifier that is used to identify a specific version of the value set to be used when validating the code. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.",
      "type" : "string"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The code that is to be validated. If a code is provided, a system or a context must be provided (if a context is provided, then the server SHALL ensure that the code is not ambiguous without a system)",
      "type" : "code"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system for the code that is to be validated",
      "type" : "uri"
    },
    {
      "name" : "systemVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The version of the system, if one was provided in the source data",
      "type" : "string"
    },
    {
      "name" : "display",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The display associated with the code, if provided. If a display is provided a code must be provided. If no display is provided, the server cannot validate the display value, but may choose to return a recommended display name in an extension in the outcome. Whether displays are case sensitive is code system dependent",
      "type" : "string"
    },
    {
      "name" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A coding to validate",
      "type" : "Coding"
    },
    {
      "name" : "codeableConcept",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A full codeableConcept to validate. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present",
      "type" : "CodeableConcept"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date for which the validation should be checked. Normally, this is the current conditions (which is the default values) but under some circumstances, systems need to validate that a correct code was used at some point in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.",
      "type" : "dateTime"
    },
    {
      "name" : "abstract",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If this parameter has a value of true, the client is stating that the validation is being performed in a context where a concept designated as 'abstract' is appropriate/allowed to be used, and the server should regard abstract codes as valid. If this parameter is fase, abstract codes are not considered to be valid.\n\nNote that. 'abstract' is a property defined by many HL7 code systems that indicates that the concept is a logical grouping concept that is not intended to be used asa 'concrete' concept to in a actual patient/care/process record. This language is borrowed from Object Orienated theory where 'asbtract' objects are never instantiated. However in the general record and terminology eco-system, there are many contexts where it is appropraite to use these codes e.g. as decision making criterion, or when editing value sets themselves. This parameter allows a client to indicate to the server that it is working in such a context.",
      "type" : "boolean"
    },
    {
      "name" : "displayLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Specifies the language to be used for description when validating the display property",
      "type" : "code"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "True if the concept details supplied are valid",
      "type" : "boolean"
    },
    {
      "name" : "message",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "Error details, if result = false. If this is provided when result = true, the message carries hints and warnings",
      "type" : "string"
    },
    {
      "name" : "display",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A valid display for the concept if the system wishes to display this to a user",
      "type" : "string"
    }
  ]
}

OperationDefinition "ValueSet-expand" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Value Set Expansion

OPERATION: Value Set Expansion

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ValueSet-expand

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.

If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.

URL: [base]/ValueSet/$expand

URL: [base]/ValueSet/[id]/$expand

Parameters

Use Name Cardinality Type Binding Documentation
IN url 0..1 uri

A canonical url for a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server

IN valueSet 0..1 ValueSet

The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion

IN valueSetVersion 0..1 string

The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.

IN context 0..1 uri

The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time

IN contextDirection 0..1 code

If a context is provided, a context direction may also be provided. Valid values are 'incoming' and 'outgoing'. The purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)

IN filter 0..1 string

A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in TerminologyCapabilities..expansion.textFilter. Typical usage of this parameter includes functionality like:

  • using left matching e.g. "acut ast"
  • allowing for wild cards such as %, &, ?
  • searching on definition as well as display(s)
  • allowing for search conditions (and / or / exclusions)

Text Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems

IN date 0..1 dateTime

The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.

IN offset 0..1 integer

Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)

IN count 0..1 integer

Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count

IN includeDesignations 0..1 boolean

Controls whether concept designations are to be included or excluded in value set expansions

IN designation 0..* string

A token that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return

IN includeDefinition 0..1 boolean

Controls whether the value set definition is included or excluded in value set expansions

IN activeOnly 0..1 boolean

Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them

IN excludeNested 0..1 boolean

Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)

IN excludeNotForUI 0..1 boolean

Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include 'abstract' codes or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.

IN excludePostCoordinated 0..1 boolean

Controls whether or not the value set expansion includes post coordinated codes

IN displayLanguage 0..1 code

Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display

IN exclude-system 0..* canonical

Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN system-version 0..* canonical

Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN check-system-version 0..* canonical

Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56

IN force-system-version 0..* canonical

Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters

OUT return 1..1 ValueSet

The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list

The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used.

If the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion.

Different servers may return different results from expanding a value set for the following reasons:

  • The underlying code systems are different (e.g. different versions, possibly with different defined behavior)
  • The server optimizes filter includes differently, such as sorting by code frequency
  • Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server

When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension http://hl7.org/fhir/StructureDefinition/valueset-unclosed can be used to indicate that the expansion is incomplete


{
  "resourceType" : "OperationDefinition",
  "id" : "ValueSet-expand",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.828Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Value Set Expansion</h2>\n <p>OPERATION: Value Set Expansion</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ValueSet-expand</pre>\n <div>\n <p>The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.</p>\n\n <p>If the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.</p>\n\n </div>\n <p>URL: [base]/ValueSet/$expand</p>\n <p>URL: [base]/ValueSet/[id]/$expand</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A canonical url for a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSet</td>\n <td>0..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>valueSetVersion</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>context</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>contextDirection</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If a context is provided, a context direction may also be provided. Valid values are 'incoming' and 'outgoing'. The purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>filter</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in \n <a href=\"terminologycapabilities.html\">TerminologyCapabilities</a>..expansion.textFilter. Typical usage of this parameter includes functionality like:\n </p>\n\n <ul>\n\n <li>using left matching e.g. \"acut ast\"</li>\n\n <li>allowing for wild cards such as %, &amp;, ?</li>\n\n <li>searching on definition as well as display(s)</li>\n\n <li>allowing for search conditions (and / or / exclusions)</li>\n\n </ul>\n\n <p>Text Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>date</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>offset</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>includeDesignations</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether concept designations are to be included or excluded in value set expansions</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>designation</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A \n <a href=\"search.html#token\">token</a> that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>includeDefinition</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether the value set definition is included or excluded in value set expansions</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>activeOnly</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludeNested</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludeNotForUI</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include \n <a href=\"codesystem.html#status\">'abstract' codes</a> or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>excludePostCoordinated</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Controls whether or not the value set expansion includes post coordinated codes</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>displayLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>exclude-system</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>check-system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>force-system-version</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"valueset.html\">ValueSet</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used.</p>\n\n <p>If the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion.</p>\n\n <p>Different servers may return different results from expanding a value set for the following reasons:</p>\n\n <ul>\n\n <li>The underlying code systems are different (e.g. different versions, possibly with different defined behavior)</li>\n\n <li>The server optimizes filter includes differently, such as sorting by code frequency</li>\n\n <li>Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server</li>\n\n </ul>\n\n <p>When a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension \n <a href=\"extension-valueset-unclosed.html\">http://hl7.org/fhir/StructureDefinition/valueset-unclosed</a> can be used to indicate that the expansion is incomplete\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Normative"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ValueSet-expand",
  "name" : "Value Set Expansion",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. \n\nIf the operation is not called at the instance level, one of the in parameters url, context or valueSet must be provided. An expanded value set will be returned, or an OperationOutcome with an error message.
",
  "code" : "expand",
  "comment" : "The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used. \n\nIf the expansion is too large (at the discretion of the server), the server MAY return an error (OperationOutcome with code too-costly). Clients can work through large flat expansions in a set of pages (partial views of the full expansion) instead of just getting the full expansion in a single exchange by using offset and count parameters, or use the count parameter to request a subset of the expansion for limited purposes. Servers are not obliged to support paging, but if they do, SHALL support both the offset and count parameters. Hierarchical expansions are not subject to paging and servers simply return the entire expansion. \n\nDifferent servers may return different results from expanding a value set for the following reasons: \n\n* The underlying code systems are different (e.g. different versions, possibly with different defined behavior) \n* The server optimizes filter includes differently, such as sorting by code frequency \n* Servers introduce arbitrary groups to assist a user to navigate the lists based either on extensions in the definition, or additional knowledge available to the server\n\nWhen a server cannot correctly expand a value set because it does not fully understand the code systems (e.g. it has the wrong version, or incomplete definitions) then it SHALL return an error. If the value set itself is unbounded due to the inclusion of post-coordinated value sets (e.g. SNOMED CT, UCUM), then the extension [http://hl7.org/fhir/StructureDefinition/valueset-unclosed](extension-valueset-unclosed.html) can be used to indicate that the expansion is incomplete",
  "resource" : [
    "ValueSet"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A canonical url for a value set. The server must know the value set (e.g. it is defined explicitly in the server's value sets, or it is defined implicitly by some code system known to the server",
      "type" : "uri"
    },
    {
      "name" : "valueSet",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The value set is provided directly as part of the request. Servers may choose not to accept value sets in this fashion",
      "type" : "ValueSet"
    },
    {
      "name" : "valueSetVersion",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The identifier that is used to identify a specific version of the value set to be used when generating the expansion. This is an arbitrary value managed by the value set author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available.",
      "type" : "string"
    },
    {
      "name" : "context",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The context of the value set, so that the server can resolve this to a value set to expand. The recommended format for this URI is [Structure Definition URL]#[name or path into structure definition] e.g. http://hl7.org/fhir/StructureDefinition/observation-hspc-height-hspcheight#Observation.interpretation. Other forms may be used but are not defined. This form is only usable if the terminology server also has access to the conformance registry that the server is using, but can be used to delegate the mapping from an application context to a binding at run-time",
      "type" : "uri"
    },
    {
      "name" : "contextDirection",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If a context is provided, a context direction may also be provided. Valid values are 'incoming' and 'outgoing'. The purpose is to inform the server whether to use the value set associated with the context for reading or writing purposes (note: for most elements, this is the same value set, but there are a few elements where the reading and writing value sets are different)",
      "type" : "code"
    },
    {
      "name" : "filter",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A text filter that is applied to restrict the codes that are returned (this is useful in a UI context). The interpretation of this is delegated to the server in order to allow to determine the most optimal search approach for the context. The server can document the way this parameter works in [TerminologyCapabilities](terminologycapabilities.html)..expansion.textFilter. Typical usage of this parameter includes functionality like:\n\n* using left matching e.g. \"acut ast\"\n* allowing for wild cards such as %, &, ?\n* searching on definition as well as display(s)\n* allowing for search conditions (and / or / exclusions)\n\nText Search engines such as Lucene or Solr, long with their considerable functionality, might also be used. The optional text search might also be code system specific, and servers might have different implementations for different code systems",
      "type" : "string"
    },
    {
      "name" : "date",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date for which the expansion should be generated. if a date is provided, it means that the server should use the value set / code system definitions as they were on the given date, or return an error if this is not possible. Normally, the date is the current conditions (which is the default value) but under some circumstances, systems need to generate an expansion as it would have been in the past. A typical example of this would be where code selection is constrained to the set of codes that were available when the patient was treated, not when the record is being edited. Note that which date is appropriate is a matter for implementation policy.",
      "type" : "dateTime"
    },
    {
      "name" : "offset",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Paging support - where to start if a subset is desired (default = 0). Offset is number of records (not number of pages)",
      "type" : "integer"
    },
    {
      "name" : "count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Paging support - how many codes should be provided in a partial page view. Paging only applies to flat expansions - servers ignore paging if the expansion is not flat. If count = 0, the client is asking how large the expansion is. Servers SHOULD honor this request for hierarchical expansions as well, and simply return the overall count",
      "type" : "integer"
    },
    {
      "name" : "includeDesignations",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether concept designations are to be included or excluded in value set expansions",
      "type" : "boolean"
    },
    {
      "name" : "designation",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "A [token](search.html#token) that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return",
      "type" : "string"
    },
    {
      "name" : "includeDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether the value set definition is included or excluded in value set expansions",
      "type" : "boolean"
    },
    {
      "name" : "activeOnly",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether inactive concepts are included or excluded in value set expansions. Note that if the value set explicitly specifies that inactive codes are included, this parameter can still remove them from a specific expansion, but this parameter cannot include them if the value set excludes them",
      "type" : "boolean"
    },
    {
      "name" : "excludeNested",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion nests codes or not (i.e. ValueSet.expansion.contains.contains)",
      "type" : "boolean"
    },
    {
      "name" : "excludeNotForUI",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion is assembled for a user interface use or not. Value sets intended for User Interface might include ['abstract' codes](codesystem.html#status) or have nested contains with items with no code or abstract = true, with the sole purpose of helping a user navigate through the list efficiently, where as a value set not generated for UI use might be flat, and only contain the selectable codes in the value set. The exact implications of 'for UI' depend on the code system, and what properties it exposes for a terminology server to use. In the FHIR Specification itself, the value set expansions are generated with excludeNotForUI = false, and the expansions used when generated schema / code etc, or performing validation, are all excludeNotForUI = true.",
      "type" : "boolean"
    },
    {
      "name" : "excludePostCoordinated",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Controls whether or not the value set expansion includes post coordinated codes",
      "type" : "boolean"
    },
    {
      "name" : "displayLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Specifies the language to be used for description in the expansions i.e. the language to be used for ValueSet.expansion.contains.display",
      "type" : "code"
    },
    {
      "name" : "exclude-system",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Code system, or a particular version of a code system to be excluded from the value set expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Specifies a version to use for a system, if the value set does not specify which one to use. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "check-system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Edge Case: Specifies a version to use for a system. If a value set specifies a different version, an error is returned instead of the expansion. The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56",
      "type" : "canonical"
    },
    {
      "name" : "force-system-version",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Edge Case: Specifies a version to use for a system. This parameter overrides any specified version in the value set (and any it depends on). The format is the same as a canonical URL: [system]|[version] - e.g. http://loinc.org|2.56. Note that this has obvious safety issues, in that it may result in a value set expansion giving a different list of codes that is both wrong and unsafe, and implementers should only use this capability reluctantly. It primarily exists to deal with situations where specifications have fallen into decay as time passes. If the value is override, the version used SHALL explicitly be represented in the expansion parameters",
      "type" : "canonical"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the expansion. Servers generating expansions SHOULD ensure that all the parameters that affect the contents of the expansion are recorded in the ValueSet.expansion.parameter list",
      "type" : "ValueSet"
    }
  ]
}

OperationDefinition "StructureMap-transform" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Model Instance Transformation

OPERATION: Model Instance Transformation

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureMap-transform

The transform operation takes input content, applies a structure map transform, and then returns the output.

URL: [base]/StructureMap/$transform

URL: [base]/StructureMap/[id]/$transform

Parameters

Use Name Cardinality Type Binding Documentation
IN source 0..1 uri

The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server

IN content 1..1 Resource

The logical content to transform

OUT return 1..1 Resource

The result of the transform

The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a Binary resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureMap-transform",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.765Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Model Instance Transformation</h2>\n <p>OPERATION: Model Instance Transformation</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureMap-transform</pre>\n <div>\n <p>The transform operation takes input content, applies a structure map transform, and then returns the output.</p>\n\n </div>\n <p>URL: [base]/StructureMap/$transform</p>\n <p>URL: [base]/StructureMap/[id]/$transform</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>source</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The logical content to transform</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the transform</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a \n <a href=\"binary.html\">Binary</a> resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureMap-transform",
  "name" : "Model Instance Transformation",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The transform operation takes input content, applies a structure map transform, and then returns the output.
",
  "code" : "transform",
  "comment" : "The input and return are specified as 'Resources'. In most usage of the $transform operation, either the input or return content is not a valid FHIR resource. In these cases, the return type is actually a [Binary](binary.html) resource. For this operation, the Binary resources may be encoded directly, using a mime-type, as shown in the example. Note: this specification does not yet address the means by which the servers may know the correct mime types for the various content involved",
  "resource" : [
    "StructureMap"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "source",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The structure map to apply. This is only needed if the operation is invoked at the resource level. If the $transform operation is invoked on a particular structure map, this will be ignored by the server",
      "type" : "uri"
    },
    {
      "name" : "content",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The logical content to transform",
      "type" : "Resource"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the transform",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "StructureDefinition-snapshot" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generate Snapshot

OPERATION: Generate Snapshot

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot

Generates a StructureDefinition instance with a snapshot, based on a differential in a specified StructureDefinition.

If the operation is not called at the instance level, either definition or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.

URL: [base]/StructureDefinition/$snapshot

URL: [base]/StructureDefinition/[id]/$snapshot

Parameters

Use Name Cardinality Type Binding Documentation
IN definition 0..1 StructureDefinition

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url 0..1 string
( token)

The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.

OUT return 1..1 StructureDefinition

The structure definition with a snapshot


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-snapshot",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.718Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Generate Snapshot</h2>\n <p>OPERATION: Generate Snapshot</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot</pre>\n <div>\n <p>Generates a \n <a href=\"structuredefinition.html\">StructureDefinition</a> instance with a snapshot, based on a differential in a specified \n <a href=\"structuredefinition.html\">StructureDefinition</a>.\n </p>\n\n <p>If the operation is not called at the instance level, either \n <em>definition</em> or \n <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.\n </p>\n\n </div>\n <p>URL: [base]/StructureDefinition/$snapshot</p>\n <p>URL: [base]/StructureDefinition/[id]/$snapshot</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>definition</td>\n <td>0..1</td>\n <td>\n <a href=\"structuredefinition.html\">StructureDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#token\">token</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"structuredefinition.html\">StructureDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The structure definition with a snapshot</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureDefinition-snapshot",
  "name" : "Generate Snapshot",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a [StructureDefinition](structuredefinition.html) instance with a snapshot, based on a differential in a specified [StructureDefinition](structuredefinition.html). \n\nIf the operation is not called at the instance level, either *definition* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored.",
  "code" : "snapshot",
  "resource" : [
    "StructureDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "definition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [StructureDefinition](structuredefinition.html) is provided directly as part of the request. Servers may choose not to accept profiles in this fashion",
      "type" : "StructureDefinition"
    },
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The StructureDefinition's canonical URL (i.e. 'StructureDefinition.url'). The server must know the structure definition, or be able to retrieve it from other known repositories.",
      "type" : "string",
      "searchType" : "token"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The structure definition with a snapshot",
      "type" : "StructureDefinition"
    }
  ]
}

OperationDefinition "StructureDefinition-questionnaire" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Build Questionnaire

OPERATION: Build Questionnaire

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire

Generates a Questionnaire instance based on a specified StructureDefinition, creating questions for each core element or extension element found in the StructureDefinition.

If the operation is not called at the instance level, one of the identifier, profile or url 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a Questionnaire instance based on the specified StructureDefinition and/or an OperationOutcome resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as "must support" will be included.

This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support "non-core" resources with minimal development effort.

URL: [base]/StructureDefinition/$questionnaire

URL: [base]/StructureDefinition/[id]/$questionnaire

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 canonical

A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN profile 0..1 string
( token)

The StructureDefinition is provided directly as part of the request. Servers may choose not to accept profiles in this fashion

IN url 0..1 canonical

The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.

IN supportedOnly 0..1 boolean

If true, the questionnaire will only include those elements marked as "mustSupport='true'" in the StructureDefinition.

OUT return 1..1 Questionnaire

The questionnaire form generated based on the StructureDefinition.

Open Issue: Ideally, extensions should be populated in the generated Questionnaire that will support taking QuestionnaireResponse resources generated from the Questionnaire and turning them back into the appropriate resources.


{
  "resourceType" : "OperationDefinition",
  "id" : "StructureDefinition-questionnaire",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.656Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Build Questionnaire</h2>\n <p>OPERATION: Build Questionnaire</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire</pre>\n <div>\n <p>Generates a \n <a href=\"questionnaire.html\">Questionnaire</a> instance based on a specified \n <a href=\"structuredefinition.html\">StructureDefinition</a>, creating questions for each core element or extension element found in the \n <a href=\"structuredefinition.html\">StructureDefinition</a>.\n </p>\n\n <p>If the operation is not called at the instance level, one of the \n <em>identifier</em>, \n <em>profile</em> or \n <em>url</em> 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a \n <a href=\"questionnaire.html\">Questionnaire</a> instance based on the specified \n <a href=\"structuredefinition.html\">StructureDefinition</a> and/or an \n <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as \"must support\" will be included.\n </p>\n\n <p>This operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support \"non-core\" resources with minimal development effort.</p>\n\n </div>\n <p>URL: [base]/StructureDefinition/$questionnaire</p>\n <p>URL: [base]/StructureDefinition/[id]/$questionnaire</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>identifier</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>profile</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#token\">token</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"structuredefinition.html\">StructureDefinition</a> is provided directly as part of the request. Servers may choose not to accept profiles in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#canonical\">canonical</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>supportedOnly</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If true, the questionnaire will only include those elements marked as \"mustSupport='true'\" in the StructureDefinition.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"questionnaire.html\">Questionnaire</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The questionnaire form generated based on the StructureDefinition.</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>\n <strong>Open Issue</strong>: Ideally, extensions should be populated in the generated \n <a href=\"questionnaire.html\">Questionnaire</a> that will support taking \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> resources generated from the Questionnaire and turning them back into the appropriate resources.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/StructureDefinition-questionnaire",
  "name" : "Build Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a [Questionnaire](questionnaire.html) instance based on a specified [StructureDefinition](structuredefinition.html), creating questions for each core element or extension element found in the [StructureDefinition](structuredefinition.html). \n\nIf the operation is not called at the instance level, one of the *identifier*, *profile* or *url* 'in' parameters must be provided. If more than one is specified, servers may raise an error or may resolve with the parameter of their choice. If called at the instance level, these parameters will be ignored. The response will contain a [Questionnaire](questionnaire.html) instance based on the specified [StructureDefinition](structuredefinition.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. Nested groups are used to handle complex structures and data types. If the 'supportedOnly' parameter is set to true, only those elements marked as \"must support\" will be included. \n\nThis operation is intended to enable auto-generation of simple interfaces for arbitrary profiles. The 'questionnaire' approach to data entry has limitations that will make it less optimal than custom-defined interfaces. However, this function may be useful for simple applications or for systems that wish to support \"non-core\" resources with minimal development effort.",
  "code" : "questionnaire",
  "comment" : "**Open Issue**: Ideally, extensions should be populated in the generated [Questionnaire](questionnaire.html) that will support taking [QuestionnaireResponse](questionnaireresponse.html) resources generated from the Questionnaire and turning them back into the appropriate resources.",
  "resource" : [
    "StructureDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "identifier",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A logical identifier (i.e. 'StructureDefinition.identifier''). The server must know the StructureDefinition or be able to retrieve it from other known repositories.",
      "type" : "canonical",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/StructureDefinition"
      ]
    },
    {
      "name" : "profile",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [StructureDefinition](structuredefinition.html) is provided directly as part of the request. Servers may choose not to accept profiles in this fashion",
      "type" : "string",
      "searchType" : "token"
    },
    {
      "name" : "url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The StructureDefinition's official URL (i.e. 'StructureDefinition.url'). The server must know the StructureDefinition or be able to retrieve it from other known repositories.",
      "type" : "canonical",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/StructureDefinition"
      ]
    },
    {
      "name" : "supportedOnly",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If true, the questionnaire will only include those elements marked as \"mustSupport='true'\" in the StructureDefinition.",
      "type" : "boolean"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The questionnaire form generated based on the StructureDefinition.",
      "type" : "Questionnaire"
    }
  ]
}

OperationDefinition "Resource-validate" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Validate a resource

OPERATION: Validate a resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-validate

The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:

  • [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules
  • create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)
  • update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)
  • delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)

Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an OperationOutcome

URL: [base]/Resource/$validate

URL: [base]/Resource/[id]/$validate

Parameters

Use Name Cardinality Type Binding Documentation
IN resource 0..1 Resource

Must be present unless the mode is "delete"

IN mode 0..1 code http://hl7.org/fhir/ValueSet/resource-validation-mode (Required)

Default is 'no action'; (e.g. general validation)

IN profile 0..1 uri

If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error

OUT return 1..1 OperationOutcome

If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)

This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.

This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.

Note: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-validate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.593Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Validate a resource</h2>\n <p>OPERATION: Validate a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-validate</pre>\n <div>\n <p>The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:</p>\n\n <ul>\n\n <li>[mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules</li>\n\n <li>create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)</li>\n\n <li>update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate)</li>\n\n <li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)</li>\n\n </ul>\n\n <p>Modes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an \n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </p>\n\n </div>\n <p>URL: [base]/Resource/$validate</p>\n <p>URL: [base]/Resource/[id]/$validate</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>0..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Must be present unless the mode is \"delete\"</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>mode</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td>\n <a href=\"valueset-resource-validation-mode.html\">http://hl7.org/fhir/ValueSet/resource-validation-mode</a> (Required)\n </td>\n <td>\n <div>\n <p>Default is 'no action'; (e.g. general validation)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>profile</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.</p>\n\n <p>This operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.</p>\n\n <p>Note: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Normative"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-validate",
  "name" : "Validate a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter: \n\n* [mode not provided]: The server checks the content of the resource against any schema, constraint rules, and other general terminology rules \n* create: The server checks the content, and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints) \n* update: The server checks the content, and then checks that it would accept it as an update against the nominated specific resource (e.g. that there are no changes to immutable fields the server does not allow to change, and checking version integrity if appropriate) \n* delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules) \n\nModes update and delete can only be used when the operation is invoked at the resource instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)",
  "code" : "validate",
  "comment" : "This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.\n\nThis operation returns a 200 OK whether or not the resource is valid. A 4xx or 5xx error means that the validation itself could not be performed, and it is unknown whether the resource is valid or not.\n\nNote: the correct behaviour of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Must be present unless the mode is \"delete\"",
      "type" : "Resource"
    },
    {
      "name" : "mode",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Default is 'no action'; (e.g. general validation)",
      "type" : "code",
      "binding" : {
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/resource-validation-mode"
      }
    },
    {
      "name" : "profile",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error",
      "type" : "uri"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "Resource-meta" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Access a list of profiles, tags, and security labels

OPERATION: Access a list of profiles, tags, and security labels

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-meta

This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:

  • system-wide: a list of all profiles, tags and security labels in use by the system
  • resource-type level: A list of all profiles, tags, and security labels for the resource type
  • individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)

URL: [base]/$meta

URL: [base]/Resource/$meta

URL: [base]/Resource/[id]/$meta

Parameters

Use Name Cardinality Type Binding Documentation
OUT return 1..1 Meta

The meta returned by the operation

At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.546Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Access a list of profiles, tags, and security labels</h2>\n <p>OPERATION: Access a list of profiles, tags, and security labels</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta</pre>\n <div>\n <p>This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:</p>\n\n <ul>\n\n <li>system-wide: a list of all profiles, tags and security labels in use by the system</li>\n\n <li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>\n\n <li>individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)</li>\n\n </ul>\n\n </div>\n <p>URL: [base]/$meta</p>\n <p>URL: [base]/Resource/$meta</p>\n <p>URL: [base]/Resource/[id]/$meta</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The meta returned by the operation</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta",
  "name" : "Access a list of profiles, tags, and security labels",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope: \n\n* system-wide: a list of all profiles, tags and security labels in use by the system \n* resource-type level: A list of all profiles, tags, and security labels for the resource type \n* individual resource level: A list of all profiles, tags, and security labels for the current version of the resource. Also, as a special case, this operation (and other meta operations) can be performed on a historical version of a resource)",
  "code" : "meta",
  "comment" : "At the system and type levels, the $meta operation is used to get a summary of all the labels that are in use across the system. The principal use for this operation is to support search e.g. what tags can be searched for. At these levels, the meta will not contain versionId, lastUpdated etc. Systems are not obligated to implement the operation at this level (and should return a 4xx error if they don't). At the resource and historical entry level, the $meta operation returns the same meta as would be returned by accessing the resource directly. This can be used to allow a system to get access to the meta-information for the resource without accessing the resource itself, e.g. for security reasons",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The meta returned by the operation",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-meta-delete" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Delete profiles, tags, and security labels for a resource

OPERATION: Delete profiles, tags, and security labels for a resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-meta-delete

This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource

URL: [base]/Resource/[id]/$meta-delete

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-delete",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.484Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Delete profiles, tags, and security labels for a resource</h2>\n <p>OPERATION: Delete profiles, tags, and security labels for a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-delete</pre>\n <div>\n <p>This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource</p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$meta-delete</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>meta</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resulting meta for the resource</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta-delete",
  "name" : "Delete profiles, tags, and security labels for a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource",
  "code" : "meta-delete",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "meta",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Profiles, tags, and security labels to delete from the existing resource. It is not an error if these tags, profiles, and labels do not exist. The identity of a tag or security label is the system+code. When matching existing tags during deletion, version and display are ignored. For profiles, matching is based on the full URL",
      "type" : "Meta"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Resulting meta for the resource",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-meta-add" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Add profiles, tags, and security labels to a resource

OPERATION: Add profiles, tags, and security labels to a resource

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-meta-add

This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource

URL: [base]/Resource/[id]/$meta-add

Parameters

Use Name Cardinality Type Binding Documentation
IN meta 1..1 Meta

Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL

OUT return 1..1 Meta

Resulting meta for the resource


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-meta-add",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.421Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Add profiles, tags, and security labels to a resource</h2>\n <p>OPERATION: Add profiles, tags, and security labels to a resource</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-meta-add</pre>\n <div>\n <p>This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource</p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$meta-add</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>meta</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Meta\">Meta</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resulting meta for the resource</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-meta-add",
  "name" : "Add profiles, tags, and security labels to a resource",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource",
  "code" : "meta-add",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "meta",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Profiles, tags, and security labels to add to the existing resource. Note that profiles, tags, and security labels are sets, and duplicates are not created. The identity of a tag or security label is the system+code. When matching existing tags during adding, version and display are ignored. For profiles, matching is based on the full URL",
      "type" : "Meta"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "Resulting meta for the resource",
      "type" : "Meta"
    }
  ]
}

OperationDefinition "Resource-graphql" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Execute a graphql statement

OPERATION: Execute a graphql statement

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-graphql

Execute a graphql statement on a since resource or against the entire system. See the Using GraphQL with FHIR page for further details.

For the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see graphQL spec for details)

URL: [base]/$graphql

URL: [base]/Resource/[id]/$graphql

Parameters

Use Name Cardinality Type Binding Documentation
IN query 1..1 string
OUT result 1..1 Binary

The content is always returned as application/json; this SHOULD be specified in the Accept header


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graphql",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.343Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Execute a graphql statement</h2>\n <p>OPERATION: Execute a graphql statement</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-graphql</pre>\n <div>\n <p>Execute a graphql statement on a since resource or against the entire system. See the \n <a href=\"graphql.html\">Using GraphQL with FHIR</a> page for further details.\n </p>\n\n <p>For the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see \n <a href=\"http://graphql.org/\">graphQL spec</a> for details)\n </p>\n\n </div>\n <p>URL: [base]/$graphql</p>\n <p>URL: [base]/Resource/[id]/$graphql</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>query</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td/>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"binary.html\">Binary</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The content is always returned as application/json; this SHOULD be specified in the Accept header</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-graphql",
  "name" : "Execute a graphql statement",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Execute a graphql statement on a since resource or against the entire system. See the [Using GraphQL with FHIR](graphql.html) page for further details.\n\nFor the purposes of graphQL compatibility, this operation can also be invoked using a POST with the graphQL as the body, or a JSON body (see [graphQL spec](http://graphql.org/) for details)",
  "code" : "graphql",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "query",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "string"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The content is always returned as application/json; this SHOULD be specified in the Accept header",
      "type" : "Binary"
    }
  ]
}

OperationDefinition "Resource-graph" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Return a graph of resources

OPERATION: Return a graph of resources

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-graph

Return an entire graph of resources based on a GraphDefinition. The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage

URL: [base]/Resource/[id]/$graph

Parameters

Use Name Cardinality Type Binding Documentation
IN graph 1..1 uri

Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point

OUT result 1..1 Bundle

The set of resources that were in the graph based on the provided definition


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-graph",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.281Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Return a graph of resources</h2>\n <p>OPERATION: Return a graph of resources</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-graph</pre>\n <div>\n <p>Return an entire graph of resources based on a \n <a href=\"graphdefinition.html\">GraphDefinition</a>. The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage\n </p>\n\n </div>\n <p>URL: [base]/Resource/[id]/$graph</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>graph</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The set of resources that were in the graph based on the provided definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-graph",
  "name" : "Return a graph of resources",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Return an entire graph of resources based on a [GraphDefinition](graphdefinition.html). The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage",
  "code" : "graph",
  "resource" : [
    "Resource"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "graph",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Servers MAY choose to allow any graph definition to be specified, but MAY require that the client choose a graph definition from a specific list of known supported definitions. The server is not required to support a formal definition of the graph on the end point",
      "type" : "uri"
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The set of resources that were in the graph based on the provided definition",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Resource-convert" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Convert from one form to another

OPERATION: Convert from one form to another

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Resource-convert

This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -> JSON or vice versa)

URL: [base]/$convert

Parameters

Use Name Cardinality Type Binding Documentation
IN input 1..1 Resource

The resource that is to be converted

OUT output 1..1 Resource

The resource after conversion

While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:

  • converting resources from one version to another
  • restructuring information in a resource (e.g. moving method into/out of Observation.code)
  • extracting data from a questionnaire
  • converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).

These variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.

For this reason, implementers should be aware that:

  • the output resource type may be different from the input resource (particularly, it might be a bundle)
  • binary resources may be represented directly using some other content-type (i.e. just post the content directly)

Implementers are encouraged to provide feedback to HL7 about their use of this operation


{
  "resourceType" : "OperationDefinition",
  "id" : "Resource-convert",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.218Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Convert from one form to another</h2>\n <p>OPERATION: Convert from one form to another</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Resource-convert</pre>\n <div>\n <p>This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -&gt; JSON or vice versa)</p>\n\n </div>\n <p>URL: [base]/$convert</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>input</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The resource that is to be converted</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>output</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The resource after conversion</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:</p>\n\n <ul>\n\n <li>converting resources from one version to another</li>\n\n <li>restructuring information in a resource (e.g. moving method into/out of Observation.code)</li>\n\n <li>extracting data from a questionnaire</li>\n\n <li>converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth).</li>\n\n </ul>\n\n <p>These variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.</p>\n\n <p>For this reason, implementers should be aware that:</p>\n\n <ul>\n\n <li>the output resource type may be different from the input resource (particularly, it might be a bundle)</li>\n\n <li>binary resources may be represented directly using some other content-type (i.e. just post the content directly)</li>\n\n </ul>\n\n <p>Implementers are encouraged to provide feedback to HL7 about their use of this operation</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Draft"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Resource-convert",
  "name" : "Convert from one form to another",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -> JSON or vice versa)",
  "code" : "convert",
  "comment" : "While the primary use of this operation is simple - converting a resource from one format to another, there are many potential uses including:\n\n* converting resources from one version to another\n* restructuring information in a resource (e.g. moving method into/out of Observation.code)\n* extracting data from a questionnaire\n* converting CDA documents or v2 messages (as a binary resource) to a bundle (or vice versa) (or even openEHR or openMHealth). \n\nThese variants would all be associated with parameters that define and control these kind of conversions, though such parameters are not defined at this time. In the absence of any parameters, simple format conversion is all that will occur.\n\nFor this reason, implementers should be aware that:\n\n* the output resource type may be different from the input resource (particularly, it might be a bundle)\n* binary resources may be represented directly using some other content-type (i.e. just post the content directly)\n\nImplementers are encouraged to provide feedback to HL7 about their use of this operation",
  "resource" : [
    "Resource"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "input",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is to be converted",
      "type" : "Resource"
    },
    {
      "name" : "output",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource after conversion",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "Questionnaire-populatelink" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generate a link to a Questionnaire completion webpage

OPERATION: Generate a link to a Questionnaire completion webpage

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink

Generates a link to a web page to be used to answer a specified Questionnaire. The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form. The specified page will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the page with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource. Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populatelink

URL: [base]/Questionnaire/[id]/$populatelink

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.

IN questionnaire 0..1 Questionnaire

The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion

IN questionnaireRef 0..1 Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

IN content 0..* Reference

Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

IN local 0..1 boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUT link 1..1 uri

The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire

OUT issues 0..1 OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-populatelink",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.156Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Generate a link to a Questionnaire completion webpage</h2>\n <p>OPERATION: Generate a link to a Questionnaire completion webpage</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink</pre>\n <div>\n <p>Generates a link to a web page to be used to answer a specified \n <a href=\"questionnaire.html\">Questionnaire</a>. The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the \n <a href=\"questionnaire.html\">Questionnaire</a>. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form. The specified page will be populated with an unanswered set of questions following the group and question structure of the specified \n <a href=\"questionnaire.html\">Questionnaire</a>. If \n <em>content</em> parameters were specified or the \n <em>local</em> parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the page with appropriate data is dependent on the questions and/or groups in the \n <a href=\"questionnaire.html\">Questionnaire</a> having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the \n <a href=\"conceptmap.html\">ConceptMap</a> resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.\n </p>\n\n </div>\n <p>URL: [base]/Questionnaire/$populatelink</p>\n <p>URL: [base]/Questionnaire/[id]/$populatelink</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>identifier</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaire</td>\n <td>0..1</td>\n <td>\n <a href=\"questionnaire.html\">Questionnaire</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaireRef</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>local</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>link</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>issues</td>\n <td>0..1</td>\n <td>\n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page \n <strong>SHOULD</strong> ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Questionnaire-populatelink",
  "name" : "Generate a link to a Questionnaire completion webpage",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a link to a web page to be used to answer a specified [Questionnaire](questionnaire.html). The form at the specified location will be pre-filled with answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html). If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a url for the web page to direct the user to. The page will allow the user to complete/verify the questionnaire answers and to submit the form. The specified page will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the page with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.",
  "code" : "populatelink",
  "comment" : "While it is theoretically possible for the questionnaire response to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The web page **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The web form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "identifier",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.",
      "type" : "uri"
    },
    {
      "name" : "questionnaire",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion",
      "type" : "Questionnaire"
    },
    {
      "name" : "questionnaireRef",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.",
      "type" : "Reference",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/Questionnaire"
      ]
    },
    {
      "name" : "content",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)",
      "type" : "Reference"
    },
    {
      "name" : "local",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.",
      "type" : "boolean"
    },
    {
      "name" : "link",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The URL for the web form that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire",
      "type" : "uri"
    },
    {
      "name" : "issues",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "Questionnaire-populatehtml" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generate HTML for Questionnaire

OPERATION: Generate HTML for Questionnaire

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml

Generates an HTML page as a Binary instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a Binary instance containing an HTML page for filling in and submitting the specified Questionnaire and/or an OperationOutcome resource with errors or warnings. The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the HTML form with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource. Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populatehtml

URL: [base]/Questionnaire/[id]/$populatehtml

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.

IN questionnaire 0..1 Questionnaire

The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion

IN questionnaireRef 0..1 Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

IN content 0..* Reference

Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

IN local 0..1 boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUT form 1..1 Binary

The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire

OUT issues 0..1 OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-populatehtml",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.093Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Generate HTML for Questionnaire</h2>\n <p>OPERATION: Generate HTML for Questionnaire</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml</pre>\n <div>\n <p>Generates an HTML page as a \n <a href=\"binary.html\">Binary</a> instance based on a specified \n <a href=\"questionnaire.html\">Questionnaire</a>, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the \n <a href=\"questionnaire.html\">Questionnaire</a>. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a \n <a href=\"binary.html\">Binary</a> instance containing an HTML page for filling in and submitting the specified \n <a href=\"questionnaire.html\">Questionnaire</a> and/or an \n <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings. The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified \n <a href=\"questionnaire.html\">Questionnaire</a>. If \n <em>content</em> parameters were specified or the \n <em>local</em> parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the HTML form with appropriate data is dependent on the questions and/or groups in the \n <a href=\"questionnaire.html\">Questionnaire</a> having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the \n <a href=\"conceptmap.html\">ConceptMap</a> resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.\n </p>\n\n </div>\n <p>URL: [base]/Questionnaire/$populatehtml</p>\n <p>URL: [base]/Questionnaire/[id]/$populatehtml</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>identifier</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaire</td>\n <td>0..1</td>\n <td>\n <a href=\"questionnaire.html\">Questionnaire</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaireRef</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>local</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>form</td>\n <td>1..1</td>\n <td>\n <a href=\"binary.html\">Binary</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>issues</td>\n <td>0..1</td>\n <td>\n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form \n <strong>SHOULD</strong> ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Questionnaire-populatehtml",
  "name" : "Generate HTML for Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates an HTML page as a [Binary](binary.html) instance based on a specified [Questionnaire](questionnaire.html), filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html). If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a [Binary](binary.html) instance containing an HTML page for filling in and submitting the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. The generated HTML form instance will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the HTML form with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.",
  "code" : "populatehtml",
  "comment" : "While it is theoretically possible for an HTML form to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. The HTML form **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. The generated HTML form is responsible for pruning the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "identifier",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.",
      "type" : "uri"
    },
    {
      "name" : "questionnaire",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion",
      "type" : "Questionnaire"
    },
    {
      "name" : "questionnaireRef",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.",
      "type" : "Reference",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/Questionnaire"
      ]
    },
    {
      "name" : "content",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Resources containing information to be used to help populate the generated HTML form. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)",
      "type" : "Reference"
    },
    {
      "name" : "local",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.",
      "type" : "boolean"
    },
    {
      "name" : "form",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The generated HTML page that supports capturing the information defined by questionnaire, possibly partially (or fully)-populated with a set of answers for the specified Questionnaire",
      "type" : "Binary"
    },
    {
      "name" : "issues",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "Questionnaire-populate" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Populate Questionnaire

OPERATION: Populate Questionnaire

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Questionnaire-populate

Generates a QuestionnaireResponse instance based on a specified Questionnaire, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the Questionnaire. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a QuestionnaireResponse instance based on the specified Questionnaire and/or an OperationOutcome resource with errors or warnings. The QuestionnaireResponse instance will be populated with an unanswered set of questions following the group and question structure of the specified Questionnaire. If content parameters were specified or the local parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the QuestionnaireResponse with appropriate data is dependent on the questions and/or groups in the Questionnaire having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the ConceptMap resource. Regardless of the mechanism used to link the questions in a questionnaire to a "known" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.

URL: [base]/Questionnaire/$populate

URL: [base]/Questionnaire/[id]/$populate

Parameters

Use Name Cardinality Type Binding Documentation
IN identifier 0..1 uri

A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.

IN questionnaire 0..1 Questionnaire

The Questionnaire is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion

IN questionnaireRef 0..1 Reference

The Questionnaire is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.

IN subject 1..1 Reference

The resource that is to be the QuestionnaireResponse.subject. The QuestionnaireResponse instance will reference the provided subject. In addition, if the local parameter is set to true, server information about the specified subject will be used to populate the instance.

IN content 0..* Reference

Resources containing information to be used to help populate the QuestionnaireResponse. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)

IN local 0..1 boolean

If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.

OUT questionnaire 1..1 QuestionnaireResponse

The partially (or fully)-populated set of answers for the specified Questionnaire

OUT issues 0..1 OperationOutcome

A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter

While it is theoretically possible for a QuestionnaireResponse instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client SHOULD ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. When creating an "empty" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with "enableWhen", "display" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a "trusted" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.


{
  "resourceType" : "OperationDefinition",
  "id" : "Questionnaire-populate",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:27.031Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Populate Questionnaire</h2>\n <p>OPERATION: Populate Questionnaire</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Questionnaire-populate</pre>\n <div>\n <p>Generates a \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance based on a specified \n <a href=\"questionnaire.html\">Questionnaire</a>, filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the \n <a href=\"questionnaire.html\">Questionnaire</a>. If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance based on the specified \n <a href=\"questionnaire.html\">Questionnaire</a> and/or an \n <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings. The \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance will be populated with an unanswered set of questions following the group and question structure of the specified \n <a href=\"questionnaire.html\">Questionnaire</a>. If \n <em>content</em> parameters were specified or the \n <em>local</em> parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> with appropriate data is dependent on the questions and/or groups in the \n <a href=\"questionnaire.html\">Questionnaire</a> having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the \n <a href=\"conceptmap.html\">ConceptMap</a> resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.\n </p>\n\n </div>\n <p>URL: [base]/Questionnaire/$populate</p>\n <p>URL: [base]/Questionnaire/[id]/$populate</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>identifier</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaire</td>\n <td>0..1</td>\n <td>\n <a href=\"questionnaire.html\">Questionnaire</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>questionnaireRef</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The \n <a href=\"questionnaire.html\">Questionnaire</a> is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The resource that is to be the \n <em>QuestionnaireResponse.subject</em>. The \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance will reference the provided subject. In addition, if the \n <em>local</em> parameter is set to true, server information about the specified subject will be used to populate the instance.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Reference\">Reference</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resources containing information to be used to help populate the \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a>. These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>local</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>questionnaire</td>\n <td>1..1</td>\n <td>\n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The partially (or fully)-populated set of answers for the specified Questionnaire</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>issues</td>\n <td>0..1</td>\n <td>\n <a href=\"operationoutcome.html\">OperationOutcome</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>While it is theoretically possible for a \n <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client \n <strong>SHOULD</strong> ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. When creating an \"empty\" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with \"enableWhen\", \"display\" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Questionnaire-populate",
  "name" : "Populate Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "Generates a [QuestionnaireResponse](questionnaireresponse.html) instance based on a specified [Questionnaire](questionnaire.html), filling in answers to questions where possible based on information provided as part of the operation or already known by the server about the subject of the [Questionnaire](questionnaire.html). If the operation is not called at the instance level, one and only one of the identifier, questionnaire or questionnaireRef 'in' parameters must be provided. If called at the instance level, these parameters will be ignored. The response will contain a [QuestionnaireResponse](questionnaireresponse.html) instance based on the specified [Questionnaire](questionnaire.html) and/or an [OperationOutcome](operationoutcome.html) resource with errors or warnings. The [QuestionnaireResponse](questionnaireresponse.html) instance will be populated with an unanswered set of questions following the group and question structure of the specified [Questionnaire](questionnaire.html). If *content* parameters were specified or the *local* parameter was set to true, some of the questions may have answers filled in as well. In the case of repeating questions or groups, typically only one repetition will be provided unless answer values exist that would support populating multiple repetitions. Population of the [QuestionnaireResponse](questionnaireresponse.html) with appropriate data is dependent on the questions and/or groups in the [Questionnaire](questionnaire.html) having metadata that allows the server to recognize the questions, e.g. through Questionnaire.item.definition or through use of the [ConceptMap](conceptmap.html) resource. Regardless of the mechanism used to link the questions in a questionnaire to a \"known\" mappable concept, solutions using this operation should ensure that the details of the question and associated linkage element are sufficiently similar as to safely allow auto-population; i.e. the question text and context must be sufficiently the same, the value set for the question must fall within the value set for the mapped element, the data types must be the same or convertible, etc.",
  "code" : "populate",
  "comment" : "While it is theoretically possible for a [QuestionnaireResponse](questionnaireresponse.html) instance to be completely auto-populated and submitted without human review, the intention of this transaction is merely to reduce redundant data entry. A client **SHOULD** ensure that a human submitter has an opportunity to review the auto-populated answers to confirm correctness as well as to complete or expand on information provided by the auto-population process. When creating an \"empty\" questionnaire, the general algorithm is to create a QuestionnaireResponse with one item for every item in the source Questionnaire, including items with \"enableWhen\", \"display\" items, etc. If a question has a default, the default answer should be populated. And the QuestionnaireResponse should point back to the originating Questionnaire. Repeating items will typically only include a single repetition. Other extensions and/or elements may also be populated if the system is aware of appropriate values. Complex form designs with conditional logic or tight constraints on cardinalities may be challenging to auto-populate. A server MAY choose to traverse the questionnaire as if it were a human respondent, answering only those questions that are enabled based on previously answered questions. However, doing so may result in minimal population. Alternatively, systems may choose to populate all known answers, independent of dependencies and other constraints. This may cause questions to be answered that should not be answered. It will be up to the client to appropriately prune the final populated questionnaire once human review has taken place. Invoking this operation with the ''content'' parameter may involve the disclosure of personally identifiable healthcare information to the system which is performing the population process. No such disclosures should be made unless the system on which the operation is being invoked is a \"trusted\" system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.",
  "resource" : [
    "Questionnaire"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "identifier",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A logical questionnaire identifier (i.e. ''Questionnaire.identifier''). The server must know the questionnaire or be able to retrieve it from other known repositories.",
      "type" : "uri"
    },
    {
      "name" : "questionnaire",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion",
      "type" : "Questionnaire"
    },
    {
      "name" : "questionnaireRef",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The [Questionnaire](questionnaire.html) is provided as a resource reference. Servers may choose not to accept questionnaires in this fashion or may fail if they cannot resolve or access the referenced questionnaire.",
      "type" : "Reference",
      "targetProfile" : [
        "http://hl7.org/fhir/StructureDefinition/Questionnaire"
      ]
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The resource that is to be the *QuestionnaireResponse.subject*. The [QuestionnaireResponse](questionnaireresponse.html) instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.",
      "type" : "Reference"
    },
    {
      "name" : "content",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "Resources containing information to be used to help populate the [QuestionnaireResponse](questionnaireresponse.html). These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials. Servers might not support all possible source materials and may ignore materials they do not recognize. (They MAY provide warnings if ignoring submitted resources.)",
      "type" : "Reference"
    },
    {
      "name" : "local",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If specified and set to 'true' (and the server is capable), the server should use what resources and other knowledge it has about the referenced subject when pre-populating answers to questions.",
      "type" : "boolean"
    },
    {
      "name" : "questionnaire",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The partially (or fully)-populated set of answers for the specified Questionnaire",
      "type" : "QuestionnaireResponse"
    },
    {
      "name" : "issues",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A list of hints and warnings about problems encountered while populating the questionnaire. These might be show to the user as an advisory note. Note: if the questionnaire cannot be populated at all, then the operation should fail, and an OperationOutcome is returned directly with the failure, rather than using this parameter",
      "type" : "OperationOutcome"
    }
  ]
}

OperationDefinition "ProcessRequest-submit" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Submit an ProcessRequest resource for assessment

OPERATION: Submit an ProcessRequest resource for assessment

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/ProcessRequest-submit

This operation is used to submit an ProcessRequest for assessment either as a single ProcessRequest resource instance or as a Bundle containing the ProcessRequest and other referenced resources, or Bundle containing a batch of ProcessRequest resources, either as single ProcessRequests resources or Bundle resources, for processing. The only input parameter is the single ProcessRequest or Bundle resource and the only output is a single ProcessResponse or other single resource, Bundle of resources or Bundles or an OperationOutcome resource.

URL: [base]/ProcessRequest/$submit

Parameters

Use Name Cardinality Type Binding Documentation
IN resource 1..1 Resource

An ProcessRequest resource or Bundle of ProcessRequests, either as individual ProcessRequest resources or as Bundles each containing a single ProcessRequest plus referenced resources.

OUT return 1..1 Resource

A resource or Bundle of responses, either as individual resources or as Bundles each containing a single focal resource plus referenced resources.


{
  "resourceType" : "OperationDefinition",
  "id" : "ProcessRequest-submit",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.953Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Submit an ProcessRequest resource for assessment</h2>\n <p>OPERATION: Submit an ProcessRequest resource for assessment</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/ProcessRequest-submit</pre>\n <div>\n <p>This operation is used to submit an ProcessRequest for assessment either as a single ProcessRequest resource instance or as a Bundle containing the ProcessRequest and other referenced resources, or Bundle containing a batch of ProcessRequest resources, either as single ProcessRequests resources or Bundle resources, for processing. The only input parameter is the single ProcessRequest or Bundle resource and the only output is a single ProcessResponse or other single resource, Bundle of resources or Bundles or an OperationOutcome resource.</p>\n\n </div>\n <p>URL: [base]/ProcessRequest/$submit</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>An ProcessRequest resource or Bundle of ProcessRequests, either as individual ProcessRequest resources or as Bundles each containing a single ProcessRequest plus referenced resources.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A resource or Bundle of responses, either as individual resources or as Bundles each containing a single focal resource plus referenced resources.</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div/>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/ProcessRequest-submit",
  "name" : "Submit an ProcessRequest resource for assessment",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation is used to submit an ProcessRequest for assessment either as a single ProcessRequest resource instance or as a Bundle containing the ProcessRequest and other referenced resources, or Bundle containing a batch of ProcessRequest resources, either as single ProcessRequests resources or Bundle resources, for processing. The only input parameter is the single ProcessRequest or Bundle resource and the only output is a single ProcessResponse or other single resource, Bundle of resources or Bundles or an OperationOutcome resource.",
  "code" : "submit",
  "resource" : [
    "ProcessRequest"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "An ProcessRequest resource or Bundle of ProcessRequests, either as individual ProcessRequest resources or as Bundles each containing a single ProcessRequest plus referenced resources.",
      "type" : "Resource"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A resource or Bundle of responses, either as individual resources or as Bundles each containing a single focal resource plus referenced resources.",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "PlanDefinition-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements

The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library

URL: [base]/PlanDefinition/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
OUT return 1..1 Library

The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition

The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.906Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library</p>\n\n </div>\n <p>URL: [base]/PlanDefinition/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/PlanDefinition-data-requirements",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library",
  "code" : "data-requirements",
  "comment" : "The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the plan definition. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the plan definition and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "PlanDefinition"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the plan definition",
      "type" : "Library"
    }
  ]
}

OperationDefinition "PlanDefinition-apply" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Apply

OPERATION: Apply

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply

The apply operation applies a PlanDefinition to a given context

URL: [base]/PlanDefinition/$apply

URL: [base]/PlanDefinition/[id]/$apply

Parameters

Use Name Cardinality Type Binding Documentation
IN planDefinition 0..1 PlanDefinition

The plan definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required

IN patient 1..1 string
( reference)

The patient that is the target of the plan to be applied

IN encounter 0..1 string
( reference)

The encounter in context, if any

IN practitioner 0..1 string
( reference)

The practitioner applying the plan definition

IN organization 0..1 string
( reference)

The organization applying the plan definition

IN userType 0..1 CodeableConcept

The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)

IN userLanguage 0..1 CodeableConcept

Preferred language of the person using the system

IN userTaskContext 0..1 CodeableConcept

The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources

IN setting 0..1 CodeableConcept

The current setting of the request (inpatient, outpatient, etc.)

IN settingContext 0..1 CodeableConcept

Additional detail about the setting of the request, if any

OUT return 1..1 CarePlan

The CarePlan that is the result of applying the plan definition

The result of this operation is a CarePlan resource with a single activity represented by a RequestGroup. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the PlanDefinition and ActivityDefinition resource documentation


{
  "resourceType" : "OperationDefinition",
  "id" : "PlanDefinition-apply",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.828Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Apply</h2>\n <p>OPERATION: Apply</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply</pre>\n <div>\n <p>The apply operation applies a PlanDefinition to a given context</p>\n\n </div>\n <p>URL: [base]/PlanDefinition/$apply</p>\n <p>URL: [base]/PlanDefinition/[id]/$apply</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>planDefinition</td>\n <td>0..1</td>\n <td>\n <a href=\"plandefinition.html\">PlanDefinition</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The plan definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>patient</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The patient that is the target of the plan to be applied</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>encounter</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The encounter in context, if any</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The practitioner applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>organization</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The organization applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userType</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userLanguage</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Preferred language of the person using the system</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>userTaskContext</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>setting</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The current setting of the request (inpatient, outpatient, etc.)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>settingContext</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#CodeableConcept\">CodeableConcept</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Additional detail about the setting of the request, if any</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"careplan.html\">CarePlan</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The CarePlan that is the result of applying the plan definition</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The result of this operation is a CarePlan resource with a single activity represented by a RequestGroup. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the PlanDefinition and ActivityDefinition resource documentation</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/PlanDefinition-apply",
  "name" : "Apply",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The apply operation applies a PlanDefinition to a given context",
  "code" : "apply",
  "comment" : "The result of this operation is a CarePlan resource with a single activity represented by a RequestGroup. The RequestGroup will have actions for each of the applicable actions in the plan based on evaluating the applicability condition in context. For each applicable action, the definition is applied as described in the $apply operation of the ActivityDefinition resource, and the resulting resource is added as an activity to the CarePlan. If the ActivityDefinition includes library references, those libraries will be available to the evaluated expressions. If those libraries have parameters, those parameters will be bound by name to the parameters given to the operation. For a more detailed description, refer to the PlanDefinition and ActivityDefinition resource documentation",
  "resource" : [
    "PlanDefinition"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "planDefinition",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The plan definition to be applied. If the operation is invoked at the instance level, this parameter is not allowed; if the operation is invoked at the type level, this parameter is required",
      "type" : "PlanDefinition"
    },
    {
      "name" : "patient",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The patient that is the target of the plan to be applied",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "encounter",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The encounter in context, if any",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The practitioner applying the plan definition",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "organization",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The organization applying the plan definition",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "userType",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The type of user initiating the request, e.g. patient, healthcare provider, or specific type of healthcare provider (physician, nurse, etc.)",
      "type" : "CodeableConcept"
    },
    {
      "name" : "userLanguage",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Preferred language of the person using the system",
      "type" : "CodeableConcept"
    },
    {
      "name" : "userTaskContext",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The task the system user is performing, e.g. laboratory results review, medication list review, etc. This information can be used to tailor decision support outputs, such as recommended information resources",
      "type" : "CodeableConcept"
    },
    {
      "name" : "setting",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The current setting of the request (inpatient, outpatient, etc.)",
      "type" : "CodeableConcept"
    },
    {
      "name" : "settingContext",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Additional detail about the setting of the request, if any",
      "type" : "CodeableConcept"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The CarePlan that is the result of applying the plan definition",
      "type" : "CarePlan"
    }
  ]
}

OperationDefinition "Patient-match" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Find patient matches using MPI based logic

OPERATION: Find patient matches using MPI based logic

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Patient-match

A Master Patient Index ( MPI ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.

To ask an MPI to match a patient, clients use the "$match" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.

URL: [base]/Patient/$match

Parameters

Use Name Cardinality Type Binding Documentation
IN resource 1..1 Resource

Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).

IN onlyCertainMatches 0..1 boolean

If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.

IN count 0..1 integer

The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned

OUT return 1..1 Bundle

A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)

The response from an "mpi" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension " match-grade" that indicates the MPI's position on the match quality.


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-match",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.765Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Find patient matches using MPI based logic</h2>\n <p>OPERATION: Find patient matches using MPI based logic</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Patient-match</pre>\n <div>\n <p>A Master Patient Index (\n <a href=\"http://en.wikipedia.org/wiki/Enterprise_master_patient_index\">MPI</a> ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.\n </p>\n\n <p>To ask an MPI to match a patient, clients use the \"$match\" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.</p>\n\n </div>\n <p>URL: [base]/Patient/$match</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>1..1</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>onlyCertainMatches</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The response from an \"mpi\" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension \"\n <a href=\"extension-match-grade.html\">match-grade</a>\" that indicates the MPI's position on the match quality.\n </p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Patient-match",
  "name" : "Find patient matches using MPI based logic",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index) ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis. \n\nTo ask an MPI to match a patient, clients use the \"$match\" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.",
  "code" : "match",
  "comment" : "The response from an \"mpi\" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension \"[match-grade](extension-match-grade.html)\" that indicates the MPI's position on the match quality.",
  "resource" : [
    "Patient"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "resource",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).",
      "type" : "Resource"
    },
    {
      "name" : "onlyCertainMatches",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If there are multiple potential matches, then the match should not return the results with this flag set to true. When false, the server may return multiple results with each result graded accordingly.",
      "type" : "boolean"
    },
    {
      "name" : "count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Patient-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Patient Record

OPERATION: Fetch Patient Record

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Patient-everything

This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.

The intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.

URL: [base]/Patient/$everything

URL: [base]/Patient/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN start 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.

IN end 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

IN _since 0..1 instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN _type 0..* code

One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the patient compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and patient records is outside the scope of this specification (though see The Smart App Launch Implementation Guide.

When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

The _since parameter is provided to support periodic queries to get additional information that has changed about the patient since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "Patient-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.703Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Patient Record</h2>\n <p>OPERATION: Fetch Patient Record</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Patient-everything</pre>\n <div>\n <p>This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.</p>\n\n <p>The intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.</p>\n\n </div>\n <p>URL: [base]/Patient/$everything</p>\n <p>URL: [base]/Patient/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>start</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>end</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_type</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply searching the patient compartment are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n\n </ul>\n\n <p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.</p>\n\n <p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and patient records is outside the scope of this specification (though see \n <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.\n </p>\n\n <p>When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made \n <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for \n <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.\n </p>\n\n <p>The _since parameter is provided to support periodic queries to get additional information that has changed about the patient since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 5
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Patient-everything",
  "name" : "Fetch Patient Record",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. \n\nThe intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned.",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply searching the patient compartment are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). \n\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment. \n\nIt is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one, or can determine an appropriate list of patients to provide data for from the context of the request. If there is no nominated patient (GET /Patient/$everything) and the context is not associated with a single patient record, the actual list of patients is all patients that the user associated with the request has access to. This may be all patients in the family that the patient has access to, or it may be all patients that a care provider has access to, or all patients on the entire record system. In such cases, the server may choose to return an error rather than all the records. Specifying the relationship between the context, a user and patient records is outside the scope of this specification (though see [The Smart App Launch Implementation Guide](http://hl7.org/fhir/smart-app-launch). \n\nWhen this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for [Searching](http.html#paging), using the [_count](search.html#count) parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.\n\nThe _since parameter is provided to support periodic queries to get additional information that has changed about the patient since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.",
  "resource" : [
    "Patient"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "start",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.",
      "type" : "date"
    },
    {
      "name" : "end",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.",
      "type" : "date"
    },
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absence of any specified types, the server returns all resource types",
      "type" : "code"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Observation-stats" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Observation Statistics

OPERATION: Observation Statistics

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Observation-stats

The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates Observation resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations.

The set of Observations is defined by 4 parameters:

  • the subject of the observations for which the statistics are being generated ( subject)
  • which observations to generate statistics for ( code and system, or coding)
  • the time period over which to generate statistics 'duration orperiod`)
  • the set of statistical analyses to return ( statistic)

Possible statistical analyses (see StatisticsCode):

  • average ("Average"): The mean of N measurements over the stated period.
  • maximum ("Maximum"): The maximum value of N measurements over the stated period.
  • minimum ("Minimum"): The minimum value of N measurements over the stated period.
  • count ("Count"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.
  • total-count ("Total Count"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.
  • median ("Median"): The median of N measurements over the stated period.
  • std-dev ("Standard Deviation"): The standard deviation of N measurements over the stated period.
  • sum ("Sum"): The sum of N measurements over the stated period.
  • variance ("Variance"): The variance of N measurements over the stated period.
  • 20-percent ("20th Percentile"): The 20th Percentile of N measurements over the stated period.
  • 80-percent ("80th Percentile"): The 80th Percentile of N measurements over the stated period.
  • 4-lower ("Lower Quartile"): The lower Quartile Boundary of N measurements over the stated period.
  • 4-upper ("Upper Quartile"): The upper Quartile Boundary of N measurements over the stated period.
  • 4-dev ("Quartile Deviation"): The difference between the upper and lower Quartiles is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.
  • 5-1 ("1st Quintile"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-2 ("2nd Quintile"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-3 ("3rd Quintile"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • 5-4 ("4th Quintile"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.
  • skew ("Skew"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: Wikipedia.
  • kurtosis ("Kurtosis"): Kurtosis is a measure of the "tailedness" of the probability distribution of a real-valued random variable. Source: Wikipedia.
  • regression ("Regression"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: Wikipedia This Statistic code will return both a gradient and an intercept value.

If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters patient, code and duration parameters. If unsuccessful, an OperationOutcome with an error message will be returned.

The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count > limit. This functionality is included with the intent of supporting graphical presentation

URL: [base]/Observation/$stats

Parameters

Use Name Cardinality Type Binding Documentation
IN subject 1..1 uri

The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations

IN code 0..* string

The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code = 2339-0 (Glucose [Mass/​volume] in Blood) will evaluate all relevant Observations with this code in Observation.code and Observation.component.code. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in .related for .related.type = 'has-member' and 2) component observations in Observation.component.

IN system 0..1 uri

The system for the code(s). Or provide a coding instead

IN coding 0..* Coding

The test code upon which the statistics are being performed, as a Coding

IN duration 0..1 decimal

The time period of interest given as hours. For example, the duration = "1" represents the last hour - the time period from on hour ago to now

IN period 0..1 Period

The time period over which the calculations to be performed, if a duration is not provided

IN statistic 1..* code

average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined here

IN include 0..1 boolean

Whether to return the observations on which the statistics are based

IN limit 0..1 positiveInt

If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to "false" the limit parameter SHALL be ignored by the server

OUT statistics 1..* Observation

A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to final.

OUT source 0..* Observation

Source observations on which the statistics are based

If modifier extensions are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.

This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-stats",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.625Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Observation Statistics</h2>\n <p>OPERATION: Observation Statistics</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Observation-stats</pre>\n <div>\n <p>The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates \n <a href=\"observation.html\">Observation</a> resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations.\n </p>\n\n <p>The set of Observations is defined by 4 parameters:</p>\n\n <ul>\n\n <li>the subject of the observations for which the statistics are being generated (\n <code>subject</code>)\n </li>\n\n <li>which observations to generate statistics for (\n <code>code</code> and \n <code>system</code>, or \n <code>coding</code>)\n </li>\n\n <li>the time period over which to generate statistics 'duration\n <code>or</code>period`)\n </li>\n\n <li>the set of statistical analyses to return (\n <code>statistic</code>)\n </li>\n\n </ul>\n\n <p>Possible statistical analyses (see \n <a href=\"valueset-observation-statistics.html\">StatisticsCode</a>):\n </p>\n\n <ul>\n\n <li>\n <strong>average</strong> (\"Average\"): The \n <a href=\"https://en.wikipedia.org/wiki/Arithmetic_mean\">mean</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>maximum</strong> (\"Maximum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Maximal_element\">maximum</a> value of N measurements over the stated period.\n </li>\n\n <li>\n <strong>minimum</strong> (\"Minimum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Minimal_element\">minimum</a> value of N measurements over the stated period.\n </li>\n\n <li>\n <strong>count</strong> (\"Count\"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.\n </li>\n\n <li>\n <strong>total-count</strong> (\"Total Count\"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.\n </li>\n\n <li>\n <strong>median</strong> (\"Median\"): The \n <a href=\"https://en.wikipedia.org/wiki/Median\">median</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>std-dev</strong> (\"Standard Deviation\"): The \n <a href=\"https://en.wikipedia.org/wiki/Standard_deviation\">standard deviation</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>sum</strong> (\"Sum\"): The \n <a href=\"https://en.wikipedia.org/wiki/Summation\">sum</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>variance</strong> (\"Variance\"): The \n <a href=\"https://en.wikipedia.org/wiki/Variance\">variance</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>20-percent</strong> (\"20th Percentile\"): The 20th \n <a href=\"https://en.wikipedia.org/wiki/Percentile\">Percentile</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>80-percent</strong> (\"80th Percentile\"): The 80th \n <a href=\"https://en.wikipedia.org/wiki/Percentile\">Percentile</a> of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-lower</strong> (\"Lower Quartile\"): The lower \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartile</a> Boundary of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-upper</strong> (\"Upper Quartile\"): The upper \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartile</a> Boundary of N measurements over the stated period.\n </li>\n\n <li>\n <strong>4-dev</strong> (\"Quartile Deviation\"): The difference between the upper and lower \n <a href=\"https://en.wikipedia.org/wiki/Quartile\">Quartiles</a> is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.\n </li>\n\n <li>\n <strong>5-1</strong> (\"1st Quintile\"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-2</strong> (\"2nd Quintile\"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-3</strong> (\"3rd Quintile\"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>5-4</strong> (\"4th Quintile\"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\n </li>\n\n <li>\n <strong>skew</strong> (\"Skew\"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: \n <a href=\"https://en.wikipedia.org/wiki/Skewness\">Wikipedia</a>.\n </li>\n\n <li>\n <strong>kurtosis</strong> (\"Kurtosis\"): Kurtosis is a measure of the \"tailedness\" of the probability distribution of a real-valued random variable. Source: \n <a href=\"https://en.wikipedia.org/wiki/Kurtosis\">Wikipedia</a>.\n </li>\n\n <li>\n <strong>regression</strong> (\"Regression\"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: \n <a href=\"https://en.wikipedia.org/wiki/Simple_linear_regression\">Wikipedia</a> This Statistic code will return both a gradient and an intercept value.\n </li>\n\n </ul>\n\n <p>If successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters \n <code>patient</code>,\n <code>code</code> and \n <code>duration</code> parameters. If unsuccessful, an \n <a href=\"operationoutcome.html\">OperationOutcome</a> with an error message will be returned.\n </p>\n\n <p>The client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count &gt; limit. This functionality is included with the intent of supporting graphical presentation</p>\n\n </div>\n <p>URL: [base]/Observation/$stats</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>code</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code =\n2339-0 (Glucose [Mass/&#8203;volume] in Blood) will evaluate all relevant Observations with this code in \n <code>Observation.code</code> and \n <code>Observation.component.code</code>. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in \n <code>.related</code> for \n <code>.related.type</code> = 'has-member' and 2) component observations in \n <code>Observation.component</code>.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>system</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#uri\">uri</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The system for the code(s). Or provide a coding instead</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>coding</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#Coding\">Coding</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The test code upon which the statistics are being performed, as a Coding</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>duration</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#decimal\">decimal</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The time period of interest given as hours. For example, the duration = \"1\" represents the last hour - the time period from on hour ago to now</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>period</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#Period\">Period</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The time period over which the calculations to be performed, if a duration is not provided</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>statistic</td>\n <td>1..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined \n <a href=\"valueset-observation-statistics.html\">here</a>\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>include</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Whether to return the observations on which the statistics are based</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>limit</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#positiveInt\">positiveInt</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to \"false\" the limit parameter SHALL be ignored by the server</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>statistics</td>\n <td>1..*</td>\n <td>\n <a href=\"observation.html\">Observation</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to \n <code>final</code>.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>source</td>\n <td>0..*</td>\n <td>\n <a href=\"observation.html\">Observation</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Source observations on which the statistics are based</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>If \n <a href=\"extensibility.html#modifierExtension\">modifier extensions</a> are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.\n </p>\n\n <p>This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Observation-stats",
  "name" : "Observation Statistics",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates [Observation](observation.html) resources having valueQuantity elements that have UCUM unit codes. Observations with a status of 'entered-in-error' will be excluded from the calculations. \r\rThe set of Observations is defined by 4 parameters:\r\r* the subject of the observations for which the statistics are being generated (`subject`)\r* which observations to generate statistics for (`code` and `system`, or `coding`)\r* the time period over which to generate statistics 'duration` or `period`)\r* the set of statistical analyses to return (`statistic`)\r\rPossible statistical analyses (see [StatisticsCode](valueset-observation-statistics.html)):\r\r - **average** (\"Average\"): The [mean](https://en.wikipedia.org/wiki/Arithmetic_mean) of N measurements over the stated period.\r\n - **maximum** (\"Maximum\"): The [maximum](https://en.wikipedia.org/wiki/Maximal_element) value of N measurements over the stated period.\r\n - **minimum** (\"Minimum\"): The [minimum](https://en.wikipedia.org/wiki/Minimal_element) value of N measurements over the stated period.\r\n - **count** (\"Count\"): The [number] of valid measurements over the stated period that contributed to the other statistical outputs.\r\n - **total-count** (\"Total Count\"): The total [number] of valid measurements over the stated period, including observations that were ignored because they did not contain valid result values.\r\n - **median** (\"Median\"): The [median](https://en.wikipedia.org/wiki/Median) of N measurements over the stated period.\r\n - **std-dev** (\"Standard Deviation\"): The [standard deviation](https://en.wikipedia.org/wiki/Standard_deviation) of N measurements over the stated period.\r\n - **sum** (\"Sum\"): The [sum](https://en.wikipedia.org/wiki/Summation) of N measurements over the stated period.\r\n - **variance** (\"Variance\"): The [variance](https://en.wikipedia.org/wiki/Variance) of N measurements over the stated period.\r\n - **20-percent** (\"20th Percentile\"): The 20th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\r\n - **80-percent** (\"80th Percentile\"): The 80th [Percentile](https://en.wikipedia.org/wiki/Percentile) of N measurements over the stated period.\r\n - **4-lower** (\"Lower Quartile\"): The lower [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\r\n - **4-upper** (\"Upper Quartile\"): The upper [Quartile](https://en.wikipedia.org/wiki/Quartile) Boundary of N measurements over the stated period.\r\n - **4-dev** (\"Quartile Deviation\"): The difference between the upper and lower [Quartiles](https://en.wikipedia.org/wiki/Quartile) is called the Interquartile range. (IQR = Q3-Q1) Quartile deviation or Semi-interquartile range is one-half the difference between the first and the third quartiles.\r\n - **5-1** (\"1st Quintile\"): The lowest of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-2** (\"2nd Quintile\"): The second of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-3** (\"3rd Quintile\"): The third of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **5-4** (\"4th Quintile\"): The fourth of four values that divide the N measurements into a frequency distribution of five classes with each containing one fifth of the total population.\r\n - **skew** (\"Skew\"): Skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or even undefined. Source: [Wikipedia](https://en.wikipedia.org/wiki/Skewness).\r\n - **kurtosis** (\"Kurtosis\"): Kurtosis is a measure of the \"tailedness\" of the probability distribution of a real-valued random variable. Source: [Wikipedia](https://en.wikipedia.org/wiki/Kurtosis).\r\n - **regression** (\"Regression\"): Linear regression is an approach for modeling two-dimensional sample points with one independent variable and one dependent variable (conventionally, the x and y coordinates in a Cartesian coordinate system) and finds a linear function (a non-vertical straight line) that, as accurately as possible, predicts the dependent variable values as a function of the independent variables. Source: [Wikipedia](https://en.wikipedia.org/wiki/Simple_linear_regression) This Statistic code will return both a gradient and an intercept value.\r\n\r\rIf successful, the operation returns an Observation resource for each code with the results of the statistical calculations as component value pairs where the component code = the statistical code. The Observation also contains the input parameters `patient`,`code` and `duration` parameters. If unsuccessful, an [OperationOutcome](operationoutcome.html) with an error message will be returned.\r\rThe client can request that all the observations on which the statistics are based be returned as well, using the include parameter. If an include parameter is specified, a limit may also be specified; the sources observations are subsetted at the server's discretion if count > limit. This functionality is included with the intent of supporting graphical presentation",
  "code" : "stats",
  "comment" : "If [modifier extensions](extensibility.html#modifierExtension) are present in the Observation, they must be accounted for by implementers. A modifier extension may affect the observation.value in a way that it should be excluded from the from the calculations.\r\rThis operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.",
  "resource" : [
    "Observation"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The subject of the relevant Observations, which has the value of the Observation.subject.reference. E.g. 'Patient/123'. Reference can be to an absolute URL, but servers only perform stats on their own observations",
      "type" : "uri"
    },
    {
      "name" : "code",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The test code(s) upon which the statistics are being performed. Provide along with a system, or as a coding. For example, the LOINC code = \r2339-0 (Glucose [Mass/​volume] in Blood) will evaluate all relevant Observations with this code in `Observation.code` and `Observation.component.code`. For LOINC codes that are panels, e.g., 85354-9(Blood pressure panel with all children optional), the stats operation returns statistics for each of the individual panel measurements. That means it will include and evaluate all values grouped by code for all the individual observations that are: 1) referenced in `.related` for `.related.type` = 'has-member' and 2) component observations in `Observation.component`.",
      "type" : "string"
    },
    {
      "name" : "system",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The system for the code(s). Or provide a coding instead",
      "type" : "uri"
    },
    {
      "name" : "coding",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The test code upon which the statistics are being performed, as a Coding",
      "type" : "Coding"
    },
    {
      "name" : "duration",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The time period of interest given as hours. For example, the duration = \"1\" represents the last hour - the time period from on hour ago to now",
      "type" : "decimal"
    },
    {
      "name" : "period",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The time period over which the calculations to be performed, if a duration is not provided",
      "type" : "Period"
    },
    {
      "name" : "statistic",
      "use" : "in",
      "min" : 1,
      "max" : "*",
      "documentation" : "average|max|min|count The statistical operations to be performed on the relevant operations. Multiple statistics operations can be specified. These codes are defined [here](valueset-observation-statistics.html)",
      "type" : "code"
    },
    {
      "name" : "include",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Whether to return the observations on which the statistics are based",
      "type" : "boolean"
    },
    {
      "name" : "limit",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If an include parameter is specified, a limit may also be specified to limit the number of source Observations returned. If the include paramter is absent or equal to \"false\" the limit parameter SHALL be ignored by the server",
      "type" : "positiveInt"
    },
    {
      "name" : "statistics",
      "use" : "out",
      "min" : 1,
      "max" : "*",
      "documentation" : "A set of observations, one observation for each code, each containing one component for each statistic. The Observation.component.code contains the statistic, and is relative to the Observation.code and cannot be interpreted independently. The Observation will also contain a subject, effectivePeriod, and code reflecting the input parameters. The status is fixed to `final`.",
      "type" : "Observation"
    },
    {
      "name" : "source",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "Source observations on which the statistics are based",
      "type" : "Observation"
    }
  ]
}

OperationDefinition "Observation-lastn" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Last N Observations Query

OPERATION: Last N Observations Query

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Observation-lastn

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the lastn query uses the normal search parameters defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.

The request for a lastn query SHALL include:

  • A $lastn operation parameter
  • A subject using either the patient or subject search parameter
  • A category parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., code or code-value-concept)

The request for a lastn query MAY include:

  • Other Observation search parameters and modifiers

The response from a lastn query is a set of observations:

  • Filtered by additional parameters
    • If not explicitly filtered by status then will include statuses of 'entered-in-error'
  • 'GROUP BY' Observation.code
    • Codes SHALL be considered equivalent if the coding.value and coding.system are the same.
    • Text only codes SHALL be treated and grouped based on the text.
    • For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.

for example:

|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]|
|---|---|---|---|
|a|b|c | 3 [a],[b],[c]|
|a|b|a,c | 2 [a.c],[b]|
|a|b|a,b | 1 [a,b]|
|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|

  • Sorted from most recent to the oldest
  • Limited to the number of requested responses per group specified by the optional max query parameter
    • In case of a tie - when the effective times for >1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in max. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.
  • If no maximum number is given then only the most recent Observation in each group is returned.

The set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the lastn query SHALL return an empty search set with no error, but may include an operation outcome with further advice.

URL: [base]/Observation/$lastn

Parameters

Use Name Cardinality Type Binding Documentation
IN max 0..1 positiveInt

max is an optional input parameter to the lastn query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query "Fetch the last 3 results for all vitals for a patient" max = 3.

OUT return 1..1 Bundle

The set of most recent N Observations that match the lastn query search criteria.

The key differences between this query operation and simply searching Observation using the combination of _count and _sort parameters are:

  • The lastn query returns only the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several "A" Observations before getting to Observation "B".
  • The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.

This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.


{
  "resourceType" : "OperationDefinition",
  "id" : "Observation-lastn",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.562Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Last N Observations Query</h2>\n <p>OPERATION: Last N Observations Query</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Observation-lastn</pre>\n <div>\n <p>The \n <em>lastn query</em> meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the \n <em>lastn</em> query uses the \n <a href=\"observation.html#search\">normal search parameters</a> defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.\n </p>\n\n <p>The request for a lastn query SHALL include:</p>\n\n <ul>\n\n <li>A \n <code>$lastn</code> operation parameter\n </li>\n\n <li>A subject using either the \n <code>patient</code> or \n <code>subject</code> search parameter\n </li>\n\n <li>A \n <code>category</code> parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., \n <code>code</code> or \n <code>code-value-concept</code>)\n </li>\n\n </ul>\n\n <p>The request for a lastn query MAY include:</p>\n\n <ul>\n\n <li>Other Observation search parameters and modifiers</li>\n\n </ul>\n\n <p>The response from a lastn query is a set of observations:</p>\n\n <ul>\n\n <li>Filtered by additional parameters\n\n <ul>\n\n <li>If not explicitly filtered by status then will include statuses of 'entered-in-error'</li>\n\n </ul>\n\n </li>\n\n <li>'GROUP BY' \n <code>Observation.code</code>\n\n <ul>\n\n <li>Codes SHALL be considered equivalent if the \n <code>coding.value</code> \n <em>and</em> \n <code>coding.system</code> are the same.\n </li>\n\n <li>Text only codes SHALL be treated and grouped based on the text.</li>\n\n <li>For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.</li>\n\n </ul>\n\n </li>\n\n </ul>\n\n <p>for example:</p>\n\n <p>|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]|\n <br/>\n|---|---|---|---|\n <br/>\n|a|b|c | 3 [a],[b],[c]|\n <br/>\n|a|b|a,c | 2 [a.c],[b]|\n <br/>\n|a|b|a,b | 1 [a,b]|\n <br/>\n|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|\n </p>\n\n <ul>\n\n <li>Sorted from most recent to the oldest</li>\n\n <li>Limited to the number of requested responses per group specified by the optional \n <em>max</em> query parameter\n\n <ul>\n\n <li>In case of a tie - when the effective times for &gt;1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in \n <em>max</em>. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.\n </li>\n\n </ul>\n\n </li>\n\n <li>If no maximum number is given then only the most recent Observation in each group is returned.</li>\n\n </ul>\n\n <p>The set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the \n <em>lastn</em> query SHALL return an empty search set with no error, but may include an operation outcome with further advice.\n </p>\n\n </div>\n <p>URL: [base]/Observation/$lastn</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>max</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#positiveInt\">positiveInt</a>\n </td>\n <td/>\n <td>\n <div>\n <p>\n <code>max</code> is an optional input parameter to the \n <em>lastn</em> query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query \"Fetch the last 3 results for all vitals for a patient\" \n <code>max</code> = 3.\n </p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The set of most recent N Observations that match the \n <em>lastn</em> query search criteria.\n </p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this query operation and simply searching Observation using the combination of \n <code>_count</code> and \n <code>_sort</code> parameters are:\n </p>\n\n <ul>\n\n <li>The \n <em>lastn</em> query returns \n <strong>only</strong> the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several \"A\" Observations before getting to Observation \"B\".\n </li>\n\n <li>The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.</li>\n\n </ul>\n\n <p>This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 3
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Observation-lastn",
  "name" : "Last N Observations Query",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The *lastn query* meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the *lastn* query uses the [normal search parameters](observation.html#search) defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.\n\nThe request for a lastn query SHALL include:\n\n* A `$lastn` operation parameter\n* A subject using either the `patient` or `subject` search parameter\n* A `category` parameter and/or a search parameter that contains a code element in its FHIRpath expression. ( e.g., `code` or `code-value-concept`)\n\nThe request for a lastn query MAY include:\n\n* Other Observation search parameters and modifiers\n\nThe response from a lastn query is a set of observations:\n\n* Filtered by additional parameters\n * If not explicitly filtered by status then will include statuses of 'entered-in-error'\n* 'GROUP BY' `Observation.code`\n * Codes SHALL be considered equivalent if the `coding.value` *and* `coding.system` are the same.\n * Text only codes SHALL be treated and grouped based on the text.\n * For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality.\n\nfor example:\n\n|Observation.code for observation a|Observation.code for observation b|Observation.code for observation c|number of groups [codes/text in each group]| \n|---|---|---|---| \n|a|b|c | 3 [a],[b],[c]| \n|a|b|a,c | 2 [a.c],[b]| \n|a|b|a,b | 1 [a,b]| \n|'textM'|'Text'|'t e x t'|3 ['text'],['Text'],['t e x t']|\n\n* Sorted from most recent to the oldest\n* Limited to the number of requested responses per group specified by the optional *max* query parameter\n * In case of a tie - when the effective times for >1 Observations are equal - both will be returned. Therefore, more Observations may be returned than is specified in *max*. For example, 4 Observations instead of 3 if the 3rd and 4th most recent observation had the same effective time.\n* If no maximum number is given then only the most recent Observation in each group is returned.\n\nThe set of returned observations should represent distinct real world observations and not the same observation with changes in status or versions. If there are no matches, the *lastn* query SHALL return an empty search set with no error, but may include an operation outcome with further advice.",
  "code" : "lastn",
  "comment" : "The key differences between this query operation and simply searching Observation using the combination of `_count` and `_sort` parameters are:\r\r* The *lastn* query returns **only** the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several \"A\" Observations before getting to Observation \"B\".\r* The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.\r\rThis operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.",
  "resource" : [
    "Observation"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "max",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "`max` is an optional input parameter to the *lastn* query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query \"Fetch the last 3 results for all vitals for a patient\" `max` = 3.",
      "type" : "positiveInt"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The set of most recent N Observations that match the *lastn* query search criteria.",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "NamingSystem-preferred-id" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch Preferred it

OPERATION: Fetch Preferred it

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id

This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:

  • a system identifier - either a URI, an OID, or a v2 table 0396 (other) code
  • a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)

and returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.

The principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.

URL: [base]/NamingSystem/$preferred-id

Parameters

Use Name Cardinality Type Binding Documentation
IN id 1..1 string

The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier

IN type 1..1 code http://hl7.org/fhir/ValueSet/namingsystem-identifier-type (Required)
OUT result 1..1 string

OIDs are return as plain OIDs (not the URI form).

Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type ( NamingSystem.uniqueId.type). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error.

If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier


{
  "resourceType" : "OperationDefinition",
  "id" : "NamingSystem-preferred-id",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.484Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch Preferred it</h2>\n <p>OPERATION: Fetch Preferred it</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id</pre>\n <div>\n <p>This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:</p>\n\n <ul>\n\n <li>a system identifier - either a URI, an OID, or a v2 table 0396 (other) code</li>\n\n <li>a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier)</li>\n\n </ul>\n\n <p>and returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known.</p>\n\n <p>The principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.</p>\n\n </div>\n <p>URL: [base]/NamingSystem/$preferred-id</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>id</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>type</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td>\n <a href=\"valueset-namingsystem-identifier-type.html\">http://hl7.org/fhir/ValueSet/namingsystem-identifier-type</a> (Required)\n </td>\n <td/>\n </tr>\n <tr>\n <td>OUT</td>\n <td>result</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>OIDs are return as plain OIDs (not the URI form).</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type (\n <a href=\"namingsystem-definitions.html#NamingSystem.uniqueId.type\">NamingSystem.uniqueId.type</a>). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error.\n </p>\n\n <p>If the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/NamingSystem-preferred-id",
  "name" : "Fetch Preferred it",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters: \n\n* a system identifier - either a URI, an OID, or a v2 table 0396 (other) code \n* a code for what kind of identifier is desired (URI, OID, v2 table 0396 identifier) \n\nand returns either the requested identifier, or an HTTP errors response with an OperationOutcome because either the provided identifier was not recognized, or the requested identiifer type is not known. \n\nThe principle use of this operation is when converting between v2, CDA and FHIR Identifier/CX/II and CodeableConcepts/C(N/W)E/CD but the operation may also find use when converting metadata such as profiles.",
  "code" : "preferred-id",
  "comment" : "Servers handle this request by finding the provided identifier in their known naming systems, and returning the requested identifier type ([NamingSystem.uniqueId.type](namingsystem-definitions.html#NamingSystem.uniqueId.type)). If there are multiple possible identifiers of the specified type (e.g. multiple OIDs) the server returns an error. \n\nIf the server wishes, it can also look through all code systems and value sets it knows about when attempting to find the requested identifier",
  "resource" : [
    "NamingSystem"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "id",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The server parses the provided id to see what type it is (mary a URI, an OID as a URI, a plain OID, or a v2 table 0396 code). If the server can't tell what type of identifier it is, it can try it as multiple types. It is an error if more than one system matches the provided identifier",
      "type" : "string"
    },
    {
      "name" : "type",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "type" : "code",
      "binding" : {
        "strength" : "required",
        "valueSet" : "http://hl7.org/fhir/ValueSet/namingsystem-identifier-type"
      }
    },
    {
      "name" : "result",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "OIDs are return as plain OIDs (not the URI form).",
      "type" : "string"
    }
  ]
}

OperationDefinition "MessageHeader-process-message" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Process Message

OPERATION: Process Message

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message

This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages.

In addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.

URL: [base]/$process-message

Parameters

Use Name Cardinality Type Binding Documentation
IN content 1..1 Bundle

The message to process (or, if using asynchronous messaging, it may be a response message to accept)

IN async 0..1 boolean

If 'true' the message is processed using the asynchronous messaging pattern

IN response-url 0..1 url

A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses

OUT return 0..1 Bundle

A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value

This operation does not use the parameters resource; the parameters "async" and "response-url" always go in the URL, if they are used, and the "content" parameter is always the body of the HTTP message.

When processing messages, a server may return one of several status codes:

  • 200 OK: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.
  • 202 Accepted: Indicates that the receiving system has accepted custody of the message
  • 204 No Content: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the messageheader-response-request extension), no response is being provided
  • 300+: Indicates that the message was not successfully processed. The server MAY return an OperationOutcome with additional information, and SHOULD do so if the response code is 400 or greater.<br/> The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.

The following rules apply when using $process-message:

  • The operation only accepts POST transactions - any other HTTP method will result in an HTTP error
  • The request content type submitted is always Bundle with type "message" containing a Message Header resource as the first resource
  • The response content type returned is always Bundle with type "message" containing a Message Header resource as the first resource, or an HTTP error
  • If the response is an error, the body SHOULD be an Errors &mp; Warning resource with full details
  • The mailbox may be authenticated using standard HTTP authentication methods, including OAuth

The $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.

In order to ensure consistency of processing, the logical rules regarding processing of Bundle.id and message id SHALL be followed when messages are processed using this operation.

The $process-message operation may be used synchronously, or asynchronously.

The following rules apply when using the $process-message operation synchronously:

  • The URL (http://server/base/$process-message) has no parameters
  • It is an error if the sender POSTs a message that requires multiple response messages
  • Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)

The following rules apply when using the $process-message operation asynchronously:

  • The URL has at least one parameter: http://server/base/$process-message?async=true
  • The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed
  • Accepting the message means that the server has understood the message enough to know where to respond
  • An OperationOutcome SHOULD be returned in either case
  • By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]
  • Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter "response-url": http://server/base/$process-message?async=true&amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)
  • The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages

{
  "resourceType" : "OperationDefinition",
  "id" : "MessageHeader-process-message",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.406Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Process Message</h2>\n <p>OPERATION: Process Message</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message</pre>\n <div>\n <p>This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages.</p>\n\n <p>In addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.</p>\n\n </div>\n <p>URL: [base]/$process-message</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>content</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The message to process (or, if using asynchronous messaging, it may be a response message to accept)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>async</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#boolean\">boolean</a>\n </td>\n <td/>\n <td>\n <div>\n <p>If 'true' the message is processed using the asynchronous messaging pattern</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>response-url</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#url\">url</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>0..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>This operation does not use the parameters resource; the parameters \"async\" and \"response-url\" always go in the URL, if they are used, and the \"content\" parameter is always the body of the HTTP message.</p>\n\n <p>When processing messages, a server may return one of several status codes:</p>\n\n <ul>\n\n <li>\n <strong>200 OK</strong>: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n </li>\n\n <li>\n <strong>202 Accepted</strong>: Indicates that the receiving system has accepted custody of the message\n </li>\n\n <li>\n <strong>204 No Content</strong>: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the \n <a href=\"extension-messageheader-response-request.html\">messageheader-response-request</a> extension), no response is being provided\n </li>\n\n <li>\n <strong>300+</strong>: Indicates that the message was not successfully processed. The server MAY return an \n <a href=\"operationoutcome.html\">OperationOutcome</a> with additional information, and SHOULD do so if the response code is 400 or greater.&lt;br/&gt;\nThe client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n </li>\n\n </ul>\n\n <p>The following rules apply when using $process-message:</p>\n\n <ul>\n\n <li>The operation only accepts POST transactions - any other HTTP method will result in an HTTP error</li>\n\n <li>The request content type submitted is always \n <a href=\"bundle.html\">Bundle</a> with type \"message\" containing a \n <a href=\"messageheader.html\">Message Header</a> resource as the first resource\n </li>\n\n <li>The response content type returned is always \n <a href=\"bundle.html\">Bundle</a> with type \"message\" containing a \n <a href=\"messageheader.html\">Message Header</a> resource as the first resource, or an HTTP error\n </li>\n\n <li>If the response is an error, the body SHOULD be an \n <a href=\"operationoutcome.html\">Errors &amp;mp; Warning</a> resource with full details\n </li>\n\n <li>The mailbox may be authenticated using standard HTTP authentication methods, including OAuth</li>\n\n </ul>\n\n <p>The $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.</p>\n\n <p>In order to ensure consistency of processing, the \n <a href=\"messaging.html#reliable\">logical rules regarding processing of Bundle.id and message id</a> SHALL be followed when messages are processed using this operation.\n </p>\n\n <p>The $process-message operation may be used synchronously, or asynchronously.</p>\n\n <p>The following rules apply when using the $process-message operation synchronously:</p>\n\n <ul>\n\n <li>The URL (http://server/base/$process-message) has no parameters</li>\n\n <li>It is an error if the sender POSTs a message that requires multiple response messages</li>\n\n <li>Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)</li>\n\n </ul>\n\n <p>The following rules apply when using the $process-message operation asynchronously:</p>\n\n <ul>\n\n <li>The URL has at least one parameter: http://server/base/$process-message?async=true</li>\n\n <li>The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed</li>\n\n <li>Accepting the message means that the server has understood the message enough to know where to respond</li>\n\n <li>An \n <a href=\"operationoutcome.html\">OperationOutcome</a> SHOULD be returned in either case\n </li>\n\n <li>By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]</li>\n\n <li>Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter \"response-url\": http://server/base/$process-message?async=true&amp;amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)</li>\n\n <li>The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages</li>\n\n </ul>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 4
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message",
  "name" : "Process Message",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. \n\nIn addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.",
  "code" : "process-message",
  "comment" : "This operation does not use the parameters resource; the parameters \"async\" and \"response-url\" always go in the URL, if they are used, and the \"content\" parameter is always the body of the HTTP message.\n\nWhen processing messages, a server may return one of several status codes:\n* **200 OK**: Indicates that the message has been fully processed. If an application-level response is expected for the submitted message, that response SHALL be returned as the body of the 200 response.\n* **202 Accepted**: Indicates that the receiving system has accepted custody of the message\n* **204 No Content**: Indicates that the message has been fully processed and would normally have had an application-level response, but because of instructions from the sender (e.g. the [messageheader-response-request](extension-messageheader-response-request.html) extension), no response is being provided\n* **300+**: Indicates that the message was not successfully processed. The server MAY return an [OperationOutcome](operationoutcome.html) with additional information, and SHOULD do so if the response code is 400 or greater.<br/>\n The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original message. Doing so SHOULD NOT result in a duplicate message response. Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.\n\nThe following rules apply when using $process-message:\n\n* The operation only accepts POST transactions - any other HTTP method will result in an HTTP error\n* The request content type submitted is always [Bundle](bundle.html) with type \"message\" containing a [Message Header](messageheader.html) resource as the first resource\n* The response content type returned is always [Bundle](bundle.html) with type \"message\" containing a [Message Header](messageheader.html) resource as the first resource, or an HTTP error\n* If the response is an error, the body SHOULD be an [Errors &mp; Warning](operationoutcome.html) resource with full details\n* The mailbox may be authenticated using standard HTTP authentication methods, including OAuth\n\nThe $process-message operation can be used by any HTTP end-point that accepts FHIR messages, not just FHIR RESTful servers.\n\nIn order to ensure consistency of processing, the [logical rules regarding processing of Bundle.id and message id](messaging.html#reliable) SHALL be followed when messages are processed using this operation.\n\nThe $process-message operation may be used synchronously, or asynchronously.\n\nThe following rules apply when using the $process-message operation synchronously:\n\n* The URL (http://server/base/$process-message) has no parameters\n* It is an error if the sender POSTs a message that requires multiple response messages\n* Servers SHALL accept multiple concurrent message submissions and process them correctly (they are allowed to process them sequentially internally, but multiple concurrent submissions is not an error in its own right)\n\nThe following rules apply when using the $process-message operation asynchronously:\n\n* The URL has at least one parameter: http://server/base/$process-message?async=true\n* The server acknowledges the message with a 200 OK with no body, or returns an HTTP error if the message cannot be processed\n* Accepting the message means that the server has understood the message enough to know where to respond\n* An [OperationOutcome](operationoutcome.html) SHOULD be returned in either case\n* By default, the server responds by invoking the $process-message using the sender's stated end-point in the message: POST [MessageHeader.source.endpoint]/$process-messages]\n* Since the source end-point may be manipulated by message transfer engines, an alternative response address may be specified using the parameter \"response-url\": http://server/base/$process-message?async=true&amp;response-url=http://server2.com/base/anything. The endpoint at the specified URL SHALL implement the signature of the $process-message operation (parameter async=true, accept a Bundle, return a 200 OK or an error)\n* The server submits response messages to the appropriate end-point with the parameter async=true. There is no response message for the response messages",
  "resource" : [
    "MessageHeader"
  ],
  "system" : true,
  "type" : false,
  "instance" : false,
  "parameter" : [
    {
      "name" : "content",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The message to process (or, if using asynchronous messaging, it may be a response message to accept)",
      "type" : "Bundle"
    },
    {
      "name" : "async",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "If 'true' the message is processed using the asynchronous messaging pattern",
      "type" : "boolean"
    },
    {
      "name" : "response-url",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "A URL to submit response messages to, if asynchronous messaging is being used, and if the MessageHeader.source.endpoint is not the appropriate place to submit responses",
      "type" : "url"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 0,
      "max" : "1",
      "documentation" : "A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "Measure-submit-data" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Submit Data

OPERATION: Submit Data

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-submit-data

The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population

URL: [base]/Measure/$submit-data

URL: [base]/Measure/[id]/$submit-data

Parameters

Use Name Cardinality Type Binding Documentation
IN measureReport 1..1 MeasureReport

The measure report being submitted

IN resource 0..* Resource

The individual resources that make up the data-of-interest being submitted

The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-submit-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.343Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Submit Data</h2>\n <p>OPERATION: Submit Data</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-submit-data</pre>\n <div>\n <p>The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population</p>\n\n </div>\n <p>URL: [base]/Measure/$submit-data</p>\n <p>URL: [base]/Measure/[id]/$submit-data</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measureReport</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The measure report being submitted</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>resource</td>\n <td>0..*</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The individual resources that make up the data-of-interest being submitted</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-submit-data",
  "name" : "Submit Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population",
  "code" : "submit-data",
  "comment" : "The effect of invoking this operation is that the submitted data is posted to the receiving system and can be used for subsequent calculation of the relevant quality measure",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "measureReport",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The measure report being submitted",
      "type" : "MeasureReport"
    },
    {
      "name" : "resource",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "The individual resources that make up the data-of-interest being submitted",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "Measure-evaluate-measure" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Evaluate Measure

OPERATION: Evaluate Measure

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure

The evaluate-measure operation is used to calculate an eMeasure and obtain the results

URL: [base]/Measure/$evaluate-measure

URL: [base]/Measure/[id]/$evaluate-measure

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN measure 0..1 string
( reference)

The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance

IN reportType 0..1 code

The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used

IN subject 0..1 string
( reference)

Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)

IN practitioner 0..1 string
( reference)

Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner

IN lastReceivedOn 0..1 dateTime

The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report

OUT return 1..1 MeasureReport

The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete

The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-evaluate-measure",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.281Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Evaluate Measure</h2>\n <p>OPERATION: Evaluate Measure</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure</pre>\n <div>\n <p>The evaluate-measure operation is used to calculate an eMeasure and obtain the results</p>\n\n </div>\n <p>URL: [base]/Measure/$evaluate-measure</p>\n <p>URL: [base]/Measure/[id]/$evaluate-measure</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measure</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>reportType</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>lastReceivedOn</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-evaluate-measure",
  "name" : "Evaluate Measure",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The evaluate-measure operation is used to calculate an eMeasure and obtain the results",
  "code" : "evaluate-measure",
  "comment" : "The effect of invoking this operation is to calculate the measure for the given subject, or all subjects if no subject is supplied, and return the results as a MeasureReport resource of the appropriate type. Note that whether or not this operation affects the state of the server depends on whether the server persists the generated MeasureReport. If the MeasureReport is not persisted, this operation can be invoked with GET",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "reportType",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The type of measure report: subject, subject-list, or population. If not specified, a default value of subject will be used if the subject parameter is supplied, otherwise, population will be used",
      "type" : "code"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Subject for which the measure will be calculated. If not specified, the measure will be calculated for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Practitioner for which the measure will be calculated. If specified, the measure will be calculated only for subjects that have a primary relationship to the identified practitioner",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date the results of this measure were last received. This parameter is only valid for patient-level reports and is used to indicate when the last time a result for this patient was received. This information can be used to limit the set of resources returned for a patient-level report",
      "type" : "dateTime"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The results of the measure calculation. See the MeasureReport resource for a complete description of the output of this operation. Note that implementations may choose to return a MeasureReport with a status of pending to indicate that the report is still being generated. In this case, the client can use a polling method to continually request the MeasureReport until the status is updated to complete",
      "type" : "MeasureReport"
    }
  ]
}

OperationDefinition "Measure-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-data-requirements

The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition

URL: [base]/Measure/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

OUT return 1..1 Library

The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure

The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.218Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition</p>\n\n </div>\n <p>URL: [base]/Measure/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-data-requirements",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition",
  "code" : "data-requirements",
  "comment" : "The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for the measure. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the libraries referenced by the measures. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period start to be 2014-01-01T00:00:00 inclusive",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering is a module-definition Library that describes the aggregate parameters, data requirements, and dependencies of the measure",
      "type" : "Library"
    }
  ]
}

OperationDefinition "Measure-collect-data" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Collect Data

OPERATION: Collect Data

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-collect-data

The collect-data operation is used to collect the data-of-interest for the given measure.

URL: [base]/Measure/$collect-data

URL: [base]/Measure/[id]/$collect-data

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN measure 0..1 string
( reference)

The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance

IN subject 0..1 string
( reference)

Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)

IN practitioner 0..1 string
( reference)

Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner

IN lastReceivedOn 0..1 dateTime

The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios

OUT measureReport 1..1 MeasureReport

A MeasureReport of type data-collection detailing the results of the operation

OUT resource 0..* Resource

The result resources that make up the data-of-interest for the measure

The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-collect-data",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.156Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Collect Data</h2>\n <p>OPERATION: Collect Data</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-collect-data</pre>\n <div>\n <p>The collect-data operation is used to collect the data-of-interest for the given measure.</p>\n\n </div>\n <p>URL: [base]/Measure/$collect-data</p>\n <p>URL: [base]/Measure/[id]/$collect-data</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>measure</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>practitioner</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>lastReceivedOn</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#dateTime\">dateTime</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>measureReport</td>\n <td>1..1</td>\n <td>\n <a href=\"measurereport.html\">MeasureReport</a>\n </td>\n <td/>\n <td>\n <div>\n <p>A MeasureReport of type data-collection detailing the results of the operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>resource</td>\n <td>0..*</td>\n <td>\n <a href=\"resource.html\">Resource</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result resources that make up the data-of-interest for the measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-collect-data",
  "name" : "Collect Data",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The collect-data operation is used to collect the data-of-interest for the given measure.",
  "code" : "collect-data",
  "comment" : "The effect of invoking this operation is to gather the data required to perform an evaluation of the measure. If the lastReceivedOn parameter is supplied, only data that is new or has been changed since the lastReceivedOn date is included in the response. Note that the resulting MeasureReport is a transient resource",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : true,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "measure",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The measure to evaluate. This parameter is only required when the operation is invoked on the resource type, it is not used when invoking the operation on a Measure instance",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Subject for which the measure will be collected. If not specified, measure data will be collected for all subjects that meet the requirements of the measure. If specified, the measure will only be calculated for the referenced subject(s)",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "practitioner",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Practitioner for which the measure will be collected. If specified, measure data will be collected only for subjects that have a primary relationship to the identified practitioner",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "lastReceivedOn",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date the results of this measure were last received. This parameter used to indicate when the last time data for this measure was collected. This information is used to support incremental data collection scenarios",
      "type" : "dateTime"
    },
    {
      "name" : "measureReport",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "A MeasureReport of type data-collection detailing the results of the operation",
      "type" : "MeasureReport"
    },
    {
      "name" : "resource",
      "use" : "out",
      "min" : 0,
      "max" : "*",
      "documentation" : "The result resources that make up the data-of-interest for the measure",
      "type" : "Resource"
    }
  ]
}

OperationDefinition "Measure-care-gaps" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Care Gaps

OPERATION: Care Gaps

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Measure-care-gaps

The care-gaps operation is used to determine gaps-in-care based on the results of quality measures

URL: [base]/Measure/$care-gaps

Parameters

Use Name Cardinality Type Binding Documentation
IN periodStart 1..1 date

The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s

IN periodEnd 1..1 date

The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive

IN topic 1..1 string

The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report

IN subject 1..1 string
( reference)

Subject for which the care gaps report will be produced

OUT return 1..1 Bundle

The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure

The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET


{
  "resourceType" : "OperationDefinition",
  "id" : "Measure-care-gaps",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.093Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Care Gaps</h2>\n <p>OPERATION: Care Gaps</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Measure-care-gaps</pre>\n <div>\n <p>The care-gaps operation is used to determine gaps-in-care based on the results of quality measures</p>\n\n </div>\n <p>URL: [base]/Measure/$care-gaps</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodStart</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>periodEnd</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>topic</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>subject</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n <br/>(\n <a href=\"search.html#reference\">reference</a>)\n </td>\n <td/>\n <td>\n <div>\n <p>Subject for which the care gaps report will be produced</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Measure-care-gaps",
  "name" : "Care Gaps",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The care-gaps operation is used to determine gaps-in-care based on the results of quality measures",
  "code" : "care-gaps",
  "comment" : "The effect of invoking this operation is to calculate a set of measures for a particular topic (e.g. Preventive Care and Screening) and return a document describing the results of each measure for the given subject. Note that it is up to the server to determine whether or not the generated care gaps report is persisted. If the server does not persist the results, the operation does not affect state and can be invoked with a GET",
  "resource" : [
    "Measure"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "periodStart",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The start of the measurement period. In keeping with the semantics of the date parameter used in the FHIR search operation, the period will start at the beginning of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period s",
      "type" : "date"
    },
    {
      "name" : "periodEnd",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive",
      "type" : "date"
    },
    {
      "name" : "topic",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The topic to be used to determine which measures are considered for the care gaps report. Any measure with the given topic will be included in the report",
      "type" : "string"
    },
    {
      "name" : "subject",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "Subject for which the care gaps report will be produced",
      "type" : "string",
      "searchType" : "reference"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the care gaps report will be returned as a document bundle with a MeasureReport entry for each included measure",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "List-find" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Find a functional list

OPERATION: Find a functional list

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/List-find

This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at Current Resource Lists. Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)

URL: [base]/List/$find

Parameters

Use Name Cardinality Type Binding Documentation
IN patient 1..1 id

The id of a patient resource located on the server on which this operation is executed

IN name 1..1 code

The code for the functional list that is being found

Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly


{
  "resourceType" : "OperationDefinition",
  "id" : "List-find",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:26.031Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Find a functional list</h2>\n <p>OPERATION: Find a functional list</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/List-find</pre>\n <div>\n <p>This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at \n <a href=\"lifecycle.html#lists\">Current Resource Lists</a>. Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)\n </p>\n\n </div>\n <p>URL: [base]/List/$find</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>patient</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#id\">id</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The id of a patient resource located on the server on which this operation is executed</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>name</td>\n <td>1..1</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The code for the functional list that is being found</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/List-find",
  "name" : "Find a functional list",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at [Current Resource Lists](lifecycle.html#lists). Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)",
  "code" : "find",
  "comment" : "Note that servers may support searching by a functional list, and not support this operation that allows clients to find the list directly",
  "resource" : [
    "List"
  ],
  "system" : false,
  "type" : true,
  "instance" : false,
  "parameter" : [
    {
      "name" : "patient",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The id of a patient resource located on the server on which this operation is executed",
      "type" : "id"
    },
    {
      "name" : "name",
      "use" : "in",
      "min" : 1,
      "max" : "1",
      "documentation" : "The code for the functional list that is being found",
      "type" : "code"
    }
  ]
}

OperationDefinition "Library-data-requirements" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Data Requirements

OPERATION: Data Requirements

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Library-data-requirements

The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition

URL: [base]/$data-requirements

URL: [base]/Library/[id]/$data-requirements

Parameters

Use Name Cardinality Type Binding Documentation
IN target 0..1 string

The target of the data requirements operation

OUT return 1..1 Library

The result of the requirements gathering

The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)


{
  "resourceType" : "OperationDefinition",
  "id" : "Library-data-requirements",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:25.968Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Data Requirements</h2>\n <p>OPERATION: Data Requirements</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Library-data-requirements</pre>\n <div>\n <p>The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition</p>\n\n </div>\n <p>URL: [base]/$data-requirements</p>\n <p>URL: [base]/Library/[id]/$data-requirements</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>target</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#string\">string</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The target of the data requirements operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"library.html\">Library</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The result of the requirements gathering</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 2
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Library-data-requirements",
  "name" : "Data Requirements",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition",
  "code" : "data-requirements",
  "comment" : "The effect of invoking this operation is to determine the aggregate set of data requirements and dependencies for a given target resource. The result is a Library resource with a type of module-definition that contains all the parameter definitions and data requirements of the target resource and any libraries referenced by it. Implementations SHOULD aggregate data requirements intelligently (i.e. by collapsing overlapping data requirements)",
  "resource" : [
    "Library"
  ],
  "system" : true,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "target",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The target of the data requirements operation",
      "type" : "string"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The result of the requirements gathering",
      "type" : "Library"
    }
  ]
}

OperationDefinition "Group-everything" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Fetch a group of Patient Records

OPERATION: Fetch a group of Patient Records

The official URL for this operation definition is:

http://hl7.org/fhir/OperationDefinition/Group-everything

This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in US-Core. Other applicable implementation guides may make additional rules about how much information that is returned.

URL: [base]/Group/[id]/$everything

Parameters

Use Name Cardinality Type Binding Documentation
IN start 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.

IN end 0..1 date

The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

IN _since 0..1 instant

Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time

IN _type 0..* code

One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types

IN _count 0..1 integer

See discussion below on the utility of paging through the results of the $everything operation

OUT return 1..1 Bundle

The bundle type is "searchset"

The key differences between this operation and simply searching the group's patients compartment are:

  • unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)
  • the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).

This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.

It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see The Smart App Launch Implementation Guide.

The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

The _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.


{
  "resourceType" : "OperationDefinition",
  "id" : "Group-everything",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:25.890Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <h2>Fetch a group of Patient Records</h2>\n <p>OPERATION: Fetch a group of Patient Records</p>\n <p>The official URL for this operation definition is: </p>\n <pre>http://hl7.org/fhir/OperationDefinition/Group-everything</pre>\n <div>\n <p>This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in \n <a href=\"http://hl7.org/fhir/us/coref\">US-Core</a>. Other applicable implementation guides may make additional rules about how much information that is returned.\n </p>\n\n </div>\n <p>URL: [base]/Group/[id]/$everything</p>\n <p>Parameters</p>\n <table class=\"grid\">\n <tr>\n <td>\n <b>Use</b>\n </td>\n <td>\n <b>Name</b>\n </td>\n <td>\n <b>Cardinality</b>\n </td>\n <td>\n <b>Type</b>\n </td>\n <td>\n <b>Binding</b>\n </td>\n <td>\n <b>Documentation</b>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>start</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>end</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#date\">date</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_since</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#instant\">instant</a>\n </td>\n <td/>\n <td>\n <div>\n <p>Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_type</td>\n <td>0..*</td>\n <td>\n <a href=\"datatypes.html#code\">code</a>\n </td>\n <td/>\n <td>\n <div>\n <p>One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>IN</td>\n <td>_count</td>\n <td>0..1</td>\n <td>\n <a href=\"datatypes.html#integer\">integer</a>\n </td>\n <td/>\n <td>\n <div>\n <p>See discussion below on the utility of paging through the results of the $everything operation</p>\n\n </div>\n </td>\n </tr>\n <tr>\n <td>OUT</td>\n <td>return</td>\n <td>1..1</td>\n <td>\n <a href=\"bundle.html\">Bundle</a>\n </td>\n <td/>\n <td>\n <div>\n <p>The bundle type is \"searchset\"</p>\n\n </div>\n </td>\n </tr>\n </table>\n <div>\n <p>The key differences between this operation and simply searching the group's patients compartment are:</p>\n\n <ul>\n\n <li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n\n <li>the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones).</li>\n\n </ul>\n\n <p>This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.</p>\n\n <p>It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see \n <a href=\"http://hl7.org/fhir/smart-app-launch\">The Smart App Launch Implementation Guide</a>.\n </p>\n\n <p>The return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made \n <a href=\"async.html\">asynchronously</a>, and associated with \n <a href=\"formats.html#bulk\">bulk data formats</a>. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for \n <a href=\"http.html#paging\">Searching</a>, using the \n <a href=\"search.html#count\">_count</a> parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.\n </p>\n\n <p>The _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.</p>\n\n </div>\n </div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger" : 1
    },
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueString" : "Trial Use"
    }
  ],
  "url" : "http://hl7.org/fhir/OperationDefinition/Group-everything",
  "name" : "Fetch a group of Patient Records",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2018-08-19T21:48:56+10:00",
  "publisher" : "HL7 (FHIR Project)",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org/fhir"
        },
        {
          "system" : "email",
          "value" : "fhir@lists.hl7.org"
        }
      ]
    }
  ],
  "description" : "This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in [US-Core](http://hl7.org/fhir/us/coref). Other applicable implementation guides may make additional rules about how much information that is returned.",
  "code" : "everything",
  "comment" : "The key differences between this operation and simply searching the group's patients compartment are: \n\n* unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) \n* the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones). \n\nThis frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. \n\nIt is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a particular group, or determine whether the context has the rights to the nominated group, if there is one, or can determine an appropriate list of groups to provide data for from the context of the request. If there is no nominated group (GET /Group/$everything) and the context is not associated with a single group record, the actual list of groups is all groups that the user associated with the request has access to. In such cases, the server may choose to return an error rather than all the records (and is likely to do so, but not required to). Specifying the relationship between the context, a user and groups is outside the scope of this specification (though see [The Smart App Launch Implementation Guide](http://hl7.org/fhir/smart-app-launch). \n\nThe return bundle from this operation is usually rather a lot of data; servers typically choose to require that such requests are made [asynchronously](async.html), and associated with [bulk data formats](formats.html#bulk). Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for [Searching](http.html#paging), using the [_count](search.html#count) parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.\n\nThe _since parameter is provided to support periodic queries to get additional information that has changed about the group since the last query. This means that the _since parameter is based on record time. The value of the _since parameter should be set to the time from the server. If using direct response, this is the timestamp in the response header. If using the async interface, this is the transaction timestamp in the json response. Servers should ensure that the timestamps a managed such that the client does not miss any changes. Clients should be able to handle getting the same response more than once in the case that the transaction falls on a time boundary. Clients should ensure that the other query parameters are constant to ensure a coherent set of records when doing periodic queries.",
  "resource" : [
    "Group"
  ],
  "system" : false,
  "type" : false,
  "instance" : true,
  "parameter" : [
    {
      "name" : "start",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.",
      "type" : "date"
    },
    {
      "name" : "end",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "The date range relates to care dates, not record currency dates - e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.",
      "type" : "date"
    },
    {
      "name" : "_since",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "Resources updated after this period will be included in the response. The intent of this parameter is to allow a client to request only records that have changed since the last request, based on either the return header time, or or (for asynchronous use), the transaction time",
      "type" : "instant"
    },
    {
      "name" : "_type",
      "use" : "in",
      "min" : 0,
      "max" : "*",
      "documentation" : "One or more parameters, each containing one or more comma-delimited FHIR resource types to include in the return resources. In the absense of any specified types, the server returns all resource types",
      "type" : "code"
    },
    {
      "name" : "_count",
      "use" : "in",
      "min" : 0,
      "max" : "1",
      "documentation" : "See discussion below on the utility of paging through the results of the $everything operation",
      "type" : "integer"
    },
    {
      "name" : "return",
      "use" : "out",
      "min" : 1,
      "max" : "1",
      "documentation" : "The bundle type is \"searchset\"",
      "type" : "Bundle"
    }
  ]
}

OperationDefinition "example" Version "1"

Tags: (no tags)  +

This Resource , XML or JSON representation, or the full version history.. provenance for this resource
Updated: by

Generated Narrative with Details

id: example

url: http://h7.org/fhir/OperationDefinition/example

version: B

name: Populate Questionnaire

status: draft

kind: operation

date: 04/08/2015

publisher: Acme Healthcare Services

contact:

description: Limited implementation of the Populate Questionnaire implemenation

useContext:

jurisdiction: United Kingdom of Great Britain and Northern Ireland (the) (Details : {urn:iso:std:iso:3166 code 'GB' = 'United Kingdom of Great Britain and Northern Ireland', given as 'United Kingdom of Great Britain and Northern Ireland (the)'})

code: populate

comment: Only implemented for Labs and Medications so far

base: OperationDefinition/Questionnaire-populate

resource: Questionnaire

system: false

type: false

instance: true

parameter

name: subject

use: in

min: 1

max: 1

documentation: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.

type: Reference

parameter

name: local

use: in

min: 0

max: 1

documentation: If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.

type: Reference

parameter

name: return

use: out

min: 1

max: 1

documentation: The partially (or fully)-populated set of answers for the specified Questionnaire

type: QuestionnaireResponse

overload

parameterName: subject, local

overload

parameterName: subject

comment: local defaults to false when not passed as a parameter


{
  "resourceType" : "OperationDefinition",
  "id" : "example",
  "meta" : {
    "versionId" : "1",
    "lastUpdated" : "2018-09-06T12:48:25.828Z"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: example</p><p><b>url</b>: <b>http://h7.org/fhir/OperationDefinition/example</b></p><p><b>version</b>: B</p><p><b>name</b>: Populate Questionnaire</p><p><b>status</b>: draft</p><p><b>kind</b>: operation</p><p><b>date</b>: 04/08/2015</p><p><b>publisher</b>: Acme Healthcare Services</p><p><b>contact</b>: </p><p><b>description</b>: Limited implementation of the Populate Questionnaire implemenation</p><p><b>useContext</b>: </p><p><b>jurisdiction</b>: United Kingdom of Great Britain and Northern Ireland (the) <span>(Details : {urn:iso:std:iso:3166 code 'GB' = 'United Kingdom of Great Britain and Northern Ireland', given as 'United Kingdom of Great Britain and Northern Ireland (the)'})</span></p><p><b>code</b>: populate</p><p><b>comment</b>: Only implemented for Labs and Medications so far</p><p><b>base</b>: <a>OperationDefinition/Questionnaire-populate</a></p><p><b>resource</b>: Questionnaire</p><p><b>system</b>: false</p><p><b>type</b>: false</p><p><b>instance</b>: true</p><blockquote><p><b>parameter</b></p><p><b>name</b>: subject</p><p><b>use</b>: in</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The resource that is to be the *QuestionnaireResponse.subject*. The [[[QuestionnaireResponse]]] instance will reference the provided subject. In addition, if the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: local</p><p><b>use</b>: in</p><p><b>min</b>: 0</p><p><b>max</b>: 1</p><p><b>documentation</b>: If the *local* parameter is set to true, server information about the specified subject will be used to populate the instance.</p><p><b>type</b>: Reference</p></blockquote><blockquote><p><b>parameter</b></p><p><b>name</b>: return</p><p><b>use</b>: out</p><p><b>min</b>: 1</p><p><b>max</b>: 1</p><p><b>documentation</b>: The partially (or fully)-populated set of answers for the specified Questionnaire</p><p><b>type</b>: QuestionnaireResponse</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject, local</p></blockquote><blockquote><p><b>overload</b></p><p><b>parameterName</b>: subject</p><p><b>comment</b>: local defaults to false when not passed as a parameter</p></blockquote></div>"
  },
  "url" : "http://h7.org/fhir/OperationDefinition/example",
  "version" : "B",
  "name" : "Populate Questionnaire",
  "status" : "draft",
  "kind" : "operation",
  "date" : "2015-08-04",
  "publisher" : "Acme Healthcare Services",
  "contact" : [
    {
      "name" : "System Administrator",
      "telecom" : [
        {
          "system" : "email",
          "value" : "beep@coyote.acme.com"
        }
      ]
    }
  ],
  "description" : "Limited implementation of the Populate Questionnaire implemenation",
  "useContext" : [
    {
      "code" : {
        "system" : "http://build.fhir.org/codesystem-usage-context-type",
        "code" : "venue",
        "display" : "Clinical Venue"
      },
      "valueCodeableConcept" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
            "code" : "IMP",
            "display" : "inpatient encounter"
          }
        ]
      }
    }
  ],
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "urn:iso:std:iso:3166",
          "