fhir_dstu2_models 1.0.2

data/lib/fhir_dstu2_models/examples/json/operation-messageheader-process-message.json

@@ -0,0 +1,67 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "MessageHeader-process-message",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Process Message</h2><p>OPERATION: Process Message</p><div><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.  This  operation is described in detail <a href=\"messaging.html#process\">on the messaging page</a></p>\n</div><p>URL: [base]/$process-message</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>content</td><td>1..1</td><td>Bundle</td><td/><td><div><p>The message to process (or, if using asynchronous messaging, it may be a response message to accept)</p>\n</div></td></tr><tr><td>IN</td><td>async</td><td>0..1</td><td>boolean</td><td/><td><div><p>If 'true' the message is processed using the asynchronous messaging pattern</p>\n</div></td></tr><tr><td>IN</td><td>response-url</td><td>0..1</td><td>uri</td><td/><td><div><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</div></td></tr><tr><td>OUT</td><td>return</td><td>0..1</td><td>Bundle</td><td/><td><div><p>A response message, if synchronous messaging is being used (mandatory in this case). For asynchronous messaging, there is no return value</p>\n</div></td></tr></table><div><p>This operation does not use the parameters resource; the parameters &quot;async&quot; and &quot;response-url&quot; always go in the URL, if they are used, and the message parameter is always the body of the HTTP message</p>\n</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message",
+  "name": "Process Message",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "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.  This  operation is described in detail [on the messaging page](messaging.html#process)",
+  "code": "process-message",
+  "notes": "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 message parameter is always the body of the HTTP message",
+  "system": true,
+  "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": "uri"
+    },
+    {
+      "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"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-patient-everything.json

@@ -0,0 +1,62 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Patient-everything",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Fetch Patient Record</h2><p>OPERATION: Fetch Patient Record</p><div><p>This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type &quot;searchset&quot;. At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, 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 principle intended use for this operation is to provide a patient with access to their entire record (e.g. &quot;Blue Button&quot;).  The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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 <a href=\"daf/daf.html\">DAF</a>. Other applicable implementation guides may make additional rules about how much information that is returned</p>\n</div><p>URL: [base]/Patient/$everything</p><p>URL: [base]/Patient/[id]/$everything</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>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 records prior to the end date are 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 records subsequent to the start date are 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 &quot;searchset&quot;</p>\n</div></td></tr></table><div><p>The key differences between this operation and simply searching the patient compartment are:<br/></p>\n<ul>\n<li>unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging)</li>\n<li>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</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</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Patient-everything",
+  "name": "Fetch Patient Record",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "description": "This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type \"searchset\". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, 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 principle intended use for this operation is to provide a patient with access to their entire record (e.g. \"Blue Button\").  The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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 [DAF](daf/daf.html). Other applicable implementation guides may make additional rules about how much information that is returned",
+  "code": "everything",
+  "notes": "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). This frees the client from needing to determine what it could or should ask for\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. 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": [
+    "Patient"
+  ],
+  "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": "return",
+      "use": "out",
+      "min": 1,
+      "max": "1",
+      "documentation": "The bundle type is \"searchset\"",
+      "type": "Bundle"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-questionnaire-populate.json

@@ -0,0 +1,97 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Questionnaire-populate",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Populate Questionnaire</h2><p>OPERATION: Populate Questionnaire</p><div><p>Generates a <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance  based on a specified <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 <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 <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance based on the specified <a href=\"questionnaire.html\">Questionnaire</a> and/or an <a href=\"operationoutcome.html\">OperationOutcome</a> resource with errors or warnings.  The <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 <a href=\"questionnaire.html\">Questionnaire</a>.  If  <em>content</em> parameters were specified or the <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 <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> with appropriate data is dependent on the questions and/or groups in the <a href=\"questionnaire.html\">Questionnaire</a> having metadata that allows the server to recognize the questions.  This might be through <em>Questionnaire.group.question.code</em>, through extensions such as the <a href=\"extension-questionnaire-dereference.html\">http://hl7.org/fhir/StructureDefinition/questionnaire-deReference</a> extension or through use of the <a href=\"conceptmap.html\">ConceptMap</a> resource.  Regardless of the mechanism used to link the questions in a questionnaire to a &quot;known&quot; 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.</p>\n</div><p>URL: [base]/Questionnaire/$populate</p><p>URL: [base]/Questionnaire/[id]/$populate</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>identifier</td><td>0..1</td><td>uri</td><td/><td><div><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</div></td></tr><tr><td>IN</td><td>questionnaire</td><td>0..1</td><td>Questionnaire</td><td/><td><div><p>The <a href=\"questionnaire.html\">Questionnaire</a> is provided directly as part of the request. Servers may choose not to accept questionnaires in this fashion</p>\n</div></td></tr><tr><td>IN</td><td>questionnaireRef</td><td>0..1</td><td>Reference</td><td/><td><div><p>The <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.</p>\n</div></td></tr><tr><td>IN</td><td>subject</td><td>1..1</td><td>Reference</td><td/><td><div><p>The resource that is to be the <em>QuestionnaireResponse.subject</em>. The <a href=\"questionnaireresponse.html\">QuestionnaireResponse</a> instance will reference the provided subject.  In addition, if the <em>local</em> parameter is set to true, server information about the specified subject will be used to populate the instance.</p>\n</div></td></tr><tr><td>IN</td><td>content</td><td>0..*</td><td>Reference</td><td/><td><div><p>Resources containing information to be used to help populate the <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 may not support all possible source materials and may ignore materials they do not recognize.  (They MAY provide warnings if ignoring submitted resources.)</p>\n</div></td></tr><tr><td>IN</td><td>local</td><td>0..1</td><td>boolean</td><td/><td><div><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</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td>QuestionnaireResponse</td><td/><td><div><p>The partially (or fully)-populated set of answers for the specified Questionnaire</p>\n</div></td></tr></table><div><p>While it is theoretically possible for a <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 <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.  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 &quot;trusted&quot; system and appropriate agreements are in place to protect the confidentiality of any information shared with that system.</p>\n</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Questionnaire-populate",
+  "name": "Populate Questionnaire",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "description": "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.  This might be through *Questionnaire.group.question.code*, through extensions such as the [[[http://hl7.org/fhir/StructureDefinition/questionnaire-deReference]]] extension 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.",
+  "code": "populate",
+  "notes": "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.  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.",
+  "system": false,
+  "type": [
+    "Questionnaire"
+  ],
+  "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]]] 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]]] 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",
+      "profile": {
+        "reference": "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]]] 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]]].  These may be FHIR resources or may be binaries containing FHIR documents, CDA documents or other source materials.  Servers may 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": "return",
+      "use": "out",
+      "min": 1,
+      "max": "1",
+      "documentation": "The partially (or fully)-populated set of answers for the specified Questionnaire",
+      "type": "QuestionnaireResponse"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-resource-meta-add.json

@@ -0,0 +1,51 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Resource-meta-add",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Add profiles, tags, and security labels to a resource</h2><p>OPERATION: Add profiles, tags, and security labels to a resource</p><div><p>This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource.   This operation can also be used on historical entries - to update them without creating a different historical version</p>\n</div><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>meta</td><td>1..1</td><td>Meta</td><td/><td><div><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</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td>Meta</td><td/><td><div><p>Resulting meta for the resource</p>\n</div></td></tr></table><div><p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p>\n</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Resource-meta-add",
+  "name": "Add profiles, tags, and security labels to a resource",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "description": "This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource.   This operation can also be used on historical entries - to update them without creating a different historical version",
+  "code": "meta-add",
+  "notes": "This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources",
+  "system": 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"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-resource-meta-delete.json

@@ -0,0 +1,51 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Resource-meta-delete",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Delete profiles, tags, and security labels for a resource</h2><p>OPERATION: Delete profiles, tags, and security labels for a resource</p><div><p>This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource.   This operation can also be used on historical entries</p>\n</div><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>meta</td><td>1..1</td><td>Meta</td><td/><td><div><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</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td>Meta</td><td/><td><div><p>Resulting meta for the resource</p>\n</div></td></tr></table><div><p>This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources</p>\n</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Resource-meta-delete",
+  "name": "Delete profiles, tags, and security labels for a resource",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "description": "This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource.   This operation can also be used on historical entries",
+  "code": "meta-delete",
+  "notes": "This operation is special in that executing this operation does not cause a new version of the resource to be created. The meta is updated directly. This is because the content in meta does not affect the meaning of the resource, and the security labels (in particular) are used to apply access rules to existing versions of resources",
+  "system": 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"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-resource-meta.json

@@ -0,0 +1,46 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Resource-meta",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Access a list of profiles, tags, and security labels</h2><p>OPERATION: Access a list of profiles, tags, and security labels</p><div><p>This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:<br/></p>\n<ul>\n<li>system-wide: a list of all profiles, tags and security labels in use by the system</li>\n<li>resource-type level: A list of all profiles, tags, and security labels for the resource type</li>\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</ul>\n</div><p>URL: [base]/$meta</p><p>URL: [base]/Resource/$meta</p><p>URL: [base]/Resource/[id]/$meta</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>OUT</td><td>return</td><td>1..1</td><td>Meta</td><td/><td><div><p>The meta returned by the operation</p>\n</div></td></tr></table><div><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 principle 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</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Resource-meta",
+  "name": "Access a list of profiles, tags, and security labels",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "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",
+  "notes": "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 principle 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",
+  "system": true,
+  "type": [
+    "Resource"
+  ],
+  "instance": true,
+  "parameter": [
+    {
+      "name": "return",
+      "use": "out",
+      "min": 1,
+      "max": "1",
+      "documentation": "The meta returned by the operation",
+      "type": "Meta"
+    }
+  ]
+}

data/lib/fhir_dstu2_models/examples/json/operation-resource-validate.json

@@ -0,0 +1,76 @@
+{
+  "resourceType": "OperationDefinition",
+  "id": "Resource-validate",
+  "text": {
+    "status": "generated",
+    "div": "<div><h2>Validate a resource</h2><p>OPERATION: Validate a resource</p><div><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:<br/></p>\n<ul>\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<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<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<li>delete: The server ignores the content, and checks that the nominated resource is allowed to be deleted (e.g. checking referential integrity rules)<br/></li>\n</ul>\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 <a href=\"operationoutcome.html\">OperationOutcome</a></p>\n</div><p>URL: [base]/Resource/$validate</p><p>URL: [base]/Resource/[id]/$validate</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>resource</td><td>0..1</td><td>Resource</td><td/><td><div><p>Must be present unless the mode is &quot;delete&quot;</p>\n</div></td></tr><tr><td>IN</td><td>mode</td><td>0..1</td><td>code</td><td><a href=\"valueset-resource-validation-mode.html\">http://hl7.org/fhir/ValueSet/resource-validation-mode</a> (Required)</td><td><div><p>Default is 'no action'; (e.g. general validation)</p>\n</div></td></tr><tr><td>IN</td><td>profile</td><td>0..1</td><td>uri</td><td/><td><div><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</div></td></tr><tr><td>OUT</td><td>return</td><td>1..1</td><td>OperationOutcome</td><td/><td><div><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</div></td></tr></table><div><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</div></div>"
+  },
+  "url": "http://hl7.org/fhir/OperationDefinition/Resource-validate",
+  "name": "Validate a resource",
+  "status": "draft",
+  "kind": "operation",
+  "publisher": "HL7 (FHIR Project)",
+  "contact": [
+    {
+      "telecom": [
+        {
+          "system": "other",
+          "value": "http://hl7.org/fhir"
+        },
+        {
+          "system": "email",
+          "value": "fhir@lists.hl7.org"
+        }
+      ]
+    }
+  ],
+  "date": "2015-10-24T07:41:03+11:00",
+  "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]]]",
+  "code": "validate",
+  "notes": "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.",
+  "system": false,
+  "type": [
+    "Resource"
+  ],
+  "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",
+        "valueSetReference": {
+          "reference": "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"
+    }
+  ]
+}