International Patient Access, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-ipa/ and changes regularly. See the Directory of published versions
Official URL: http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-condition | Version: 1.1.0 | |||
Standards status: Trial-use | Computable Name: IPACondition | |||
Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License |
Minimum expectations for a Condition resource when accessed via an International Patient Access API. This profile communicates information about a patient's condition or diagnosis, such as recording primary and secondary diagnoses for encounters or justification for past medications. For the use of the condition resource to get a list of the patient's current problem list, use the IPA-Problem-List-Item profile instead. The difference between this profile and the IPA Problem List Item profile is that this profile does not specify or require a category.
The following data elements must always be present (in other words, mandatory resource properties where the minimum cardinality is 1) or must be supported (Must Support definition). Servers cannot restrict access to mandatory elements when authorizing an application. However, servers may choose to provide additional information or may be required to do so by national or other profiles that apply to the server's context.
Each Condition SHALL have:
Applications must also support:
Clients can access a Condition resources using:
GET [url]/Condition/[id]
where id is found in some other resource that refers to a Condition. The result of this read is a Condition resource, or an error if there is no resource the client can access for that id. Alternatively, the client may search for condition resources.
All Condition resources are required to have a code, but the coding systems used around the world and even within jurisdictions very wildly. This specification does not fix any kind of value set that controls what kind of codes can be used - other national specifications etc will place their own restrictions on the codes.
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.
clinicalStatus
and verificationStatus
and display and process them correctlyUsage:
Description of Profiles, Differentials, Snapshots and how the different presentations work.
Other representations of profile: CSV, Excel, Schematron