If the client supports the AllergyIntolerance resource, the client SHALL support the IPA profile and the conformance expectations for the AllergyIntolerance resource.

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

If the client supports the Condition resource, the client SHALL support the IPA profile and the conformance expectations for the Condition resource.

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.

If the client supports the DocumentReference resource, the client SHALL support the IPA profile and the conformance expectations for the DocumentReference resource.

If the client supports the Immunization resource, the client SHALL support the IPA profile and the conformance expectations for the Immunization resource.

If the client supports the the MedicationStatement or MedicationRequest resource, the client SHALL support the IPA profile and the conformance expectations for the Medication resource.

If the client supports the MedicationRequest resource, the client SHALL support the IPA profile and the conformance expectations for the MedicationStatement, MedicationRequest and Medication resource.

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").

If the client supports the MedicationStatement resource, the client SHALL support the IPA profile and the conformance expectations for the MedicationStatement, MedicationRequest and Medication resource.

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

The MedicationStatement 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

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

If the client supports the Observation resource, the client SHALL support the IPA profile and the conformance expectations for the Observation resource.

Client applications SHALL be able to access the patient record using the following API call:

GET [url]/Patient/[id]

Client application MAY use these search parameters that servers are required to support to access the patient record:

• _id
• 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

If the client supports the Practitioner resource, the client SHALL support the IPA profile and the conformance expectations for the Practitioner resource.

If the client supports the PractitionerRole resource, the client SHALL support the IPA profile and the conformance expectations for the PractitionerRole resource.