http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-problem-list-item

Client applications should be prepared to encounter codes they do not recognize and handle the records accordingly. Servers SHOULD populate Condition.code.coding.display and/or Condition.code.text so that clients can always at least display the condition even if they do not know the codes that are used. Clients should be careful making use of the code search parameter given that the codes used vary so much.

Safety Issues:

• Clients SHALL not treat all conditions as if they are part of the patient's current problem list
  • Note that some Condition resources may not have these status codes - this is usually due to poor record keeping reflected in legacy data
  • Servers SHOULD avoid leaving these status codes missing
• Clients SHALL pay attention to the clinicalStatus and verificationStatus and display and process them correctly
• Clients SHALL still work safely when the server does not support all the search parameters listed here.

The MedicationStatement and MedicationRequest resources can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationStatement or a MedicationRequest, then the READ and SEARCH Criteria SHALL be supported.

Clients SHALL query for both MedicationStatement and MedicationRequest when fetching patient Medication information.

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include parameter for searching this element. The client application SHALL support all methods. For example, A server SHALL be capable of returning all medications for a patient using one of or both:

GET /MedicationStatement?patient=[id]

GET /MedicationStatement?patient=[id]&_include=MedicationStatement:medication

When representing a prescribed medication, servers SHOULD use codings at the level of a clinical drug rather than ingredient or dose form (e.g. "loratadine 10mg oral tablet", rather than a bare ingredient like "loratadine" or a dose form like "loratadine oral tablet").

Clients SHALL query for both MedicationStatement and MedicationRequest when fetching patient Medication information.

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include parameter for searching this element. The client application SHALL support all methods.

http://hl7.org/fhir/StructureDefinition/vitalsigns

Servers SHALL support the capability for a client application to access the patient record using any of the following API calls:

GET [url]/Patient/[id]

GET [url]/Patient?_id=[id]

GET [url]/Patient?identifier=[identifier]

Servers are not required to support any additional search parameters, and clients SHOULD not expect servers to do so.

Additional rules and guidance for supporting Patient.link:

• The server:
  • SHALL have no more than one Patient with a status of active = "true" from the server being queried
  • MAY include inactive patients on the same server
  • MAY include inactive or active patients from a different server
  • When returning a search Bundle that contains more than one Patient record for the same patient, the Patient record(s) SHALL use the Patient.link attribute to cross-link the Patient resources.
• The client:
  • SHALL be able to follow the link(s) to the other Patient resource(s) and understand the direction of the link (in other words, which Patient is linked to which other Patient)
  • SHALL understand the Patient.link.type code which defines the type of link between this Patient resource and another Patient resource
  • SHALL be aware of the linked Patient active flag and that inactive patients may have relevant information