Primary Care
0.1.0-dft-preBallot 
dft-preBallot - This is the first draft of the P-Care IG. For a full list of available versions, see the Directory of published versions
Conformance Guidance
Most conformance expectations in this specification are defined in the formal formal FHIR artifacts. This section provides additional guidance for expectations that cannot be expressed in those artifacts.
Conformance Language
This guide follows the conformance language conventions of the FHIR core specification. The uppercase terms SHALL, SHALL NOT, SHOULD, and *MAY have the meanings defined there. Free-text statements that do not use an uppercase conformance term are not testable and are not required for conformance.
Not every expectation in this specification is expressed as a SHALL. An EMR may claim conformance with the implementation guide when it does not support a feature identified as SHOULD or MAY. However, implementers are encouraged to support these features and should recognize that a future version may strengthen an expectation from SHOULD to SHALL.
Supported Resources
Conformance with this implementation guide is assessed against the resources identified in the Capability Statement. That statement lists every resource an EMR could potentially support. Individual resources do not carry unconditional conformance requirements because support depends on the data the EMR maintains.
Conformant EMRs SHALL provide RESTful interfaces for every resource for which they maintain discrete data.
For example, an EMR that does not capture discrete family history information - because the information is not tracked or exists only in free-text notes - is not expected to support the FamilyMemberHistory resource. If the EMR does capture discrete information about specific family members, all requirements in the FamilyMemberHistory CapabilityStatement and associated profile apply.
Supported Search Parameters
Each resource search parameter in the CapabilityStatement has a conformance level, most commonly SHALL. This requirement is conditional and applies only when both of the following conditions are met:
- The EMR supports the search interaction; this interaction is not always designated SHALL, even if some search parameters are SHALL.
- The EMR supports the data element indexed by the search parameter. The underlying element may carry a
populate-if-knownobligation or a SHOULD, rather than a SHALL, so an EMR may legitimately be unable to process it.
All search parameters listed in this guide also list search parameter combinations. The presence of a search parameter combination means that those parameters cannot be sent on their own, they SHALL be sent in one of the allowed combinations. It is always permitted to send additional search parameters as additional filters on a defined search parameter combination. In this guide, the search parameter combinations are present to enforce that all searches are specific to a particular patient.
The _content Search Parameter
Unlike most search parameters, _content does not target a specific field or defined set of fields. It is intended to search the entire resource and may support compound logic such as and and or, although that capability is not required. Because the parameter is broadly defined, consistent implementation and the indexing needed to support it can be difficult.
For this version of the implementation guide, _content is treated as a simple, text-based contains search across an explicit set of elements and properties for each resource. It is not a semantic search. For example, a search for "hypertension" would match "no hypertension," but would not match "hypertensive."
The searchable data elements for each resource are listed in the following table.
| Resource | Searched Elements |
|---|---|
| AllergyIntolerance | code, reaction.substance, reaction.manifestation, reaction.description, note, reaction.note |
| Condition | code, severity, bodySite, stage.summary, note |
| DiagnosticReport | code, category, conclusion, conclusionCode, presentedForm.title, presentedForm.data |
| DocumentReference | type, content.attachment.title, author, context.practiceSetting, context.facilityType, context.event, content.attachment.data |
| Binary | contentType, data |
| Encounter | class, type, reasonCode |
| FamilyMemberHistory | relationship, condition.code, Condition.onset[x], condition.note, note |
| HealthcareService | name, type, comment, extraDetails |
| ImagingStudy | procedureCode, reasonCode, series.modality |
| Immunization | vaccineCode, site, route, reasonCode |
| Location | name, alias, description, type, address |
| Medication | code, form, incredient.itemCodeableConcept |
| MedicationRequest | medicationCodeableConcept, medicationReference.display, Medication.code, reasonCode, dosageInstruction.text |
| MedicationStatement | medicationCodeableConcept, medicationReference.display, Medication.code, reasonCode, dosage.text, dosage.route |
| Observation | code, valueString, valueCodeableConcept, valueAttachment, referenceRange.text, component.code, component.valueString, component.valueCodeableConcept, component.valueAttachment, component.interpretation, component.referenceRange.text |
| Organization | name, alias, type, address |
| Procedure | code |
| ServiceRequest | code, category, reasonCode, note |
- When the text-based contains search is used across multiple data elements in the same resource, the result be will evaluated based on an OR condition
- When a listed element has a complex type, the search applies to all descendant elements of type string. For example:
- For CodeableConcept, search
CodeableConcept.text,CodeableConcept.coding.display, andCodeableConcept.coding.version. - For HumanName, search
text,family,given,prefix, andsuffix.
In addition, for coded data (code, Coding, CodeableConcept), when a display name is not included and EMR knows the code system, the indexing also includes the resolved display name. For example, if an Observation has a LOINC code 3141-9 (Body weight Measured) and system with no display name, an app searching for 'weight' using _content would match on the Observation because the EHR would have indexed on the resolved display name for the code, even though the display name did not appear in the instance.
If the element has a type of base64, the expectation is that the content is parsed before indexing based on mime type as follows:
- application/pdf: metadata, text content, OCRed content if PDF is a scanned image
- image/jpeg, image/png: OCRed version of content
- text: content
- application/fhir+json, application/fhir+xml: Narrative of resources
- text/xml (if a CDA document): CDA narrative
- text/html: text-renderable content
As described in Conformance Guidance, requirements for this search parameter may expand in a future release.
Omitted, Unknown, and Negative Information
FHIR provides different mechanisms for representing missing element values and meaningful assertions about the absence or availability of clinical information. These mechanisms have distinct semantics and SHALL NOT be used interchangeably.
Data Absent Reason
As discussed in the CA Core+ specification and the Future Enhancements page, FHIR permits certain elements, including elements with a minimum cardinality of 1 or greater and without a required terminology binding, to carry the Data Absent Reason extension instead of an expected value or child elements.
Data Absent Reason SHALL be used only to explain why the normally expected value of an element is missing. It does not assert that the underlying clinical condition, allergy, procedure, medication, or other event is absent.
For example, Data Absent Reason may be appropriate when:
- an allergy is known, but its
onset[x]is unknown; - a procedure is known to have occurred, but its
performed[x]value is unavailable; or - another expected data element cannot be provided.
Data Absent Reason SHALL NOT be used to represent clinical assertions such as "no known allergies", "no known procedures", or "clinical history unavailable". Where an applicable terminology provides a code representing the intended assertion, that coded value SHALL be used.
Implementers SHALL NOT provide both a coded value and a Data Absent Reason extension on the same element. A coded value states the value of the element, while Data Absent Reason indicates that the value is missing.
Resource-Specific Missing Data Mechanisms
Where FHIR defines a resource-specific mechanism for representing missing or unavailable information, that mechanism SHALL be used when appropriate to the use case. Examples include Observation.dataAbsentReason and Composition.section.emptyReason. These mechanisms are preferred over the generic Data Absent Reason extension when applicable.
Population Expectations
Conformant EMRs SHOULD avoid extensions such as data-absent-reason and provide a value for simple data types, or useful child elements for backbone and complex data types, whenever the element has a support obligation and a minimum cardinality of 1 or greater.
Although "useful" is context-dependent, it can usually be interpreted consistently. For example, a HumanName or ContactPoint containing only a period and no identifying or contact information would not reasonably be useful. This expectation is a SHOULD, rather than a SHALL, to accommodate legacy and externally sourced data and because the necessary analysis to define more precise population requirements has not yet been completed. As noted in the Future Enhancements page, population and support expectations for datatype components are not always explicit in this guide's profiles.
Data Absent Reason SHALL NOT be used merely to avoid satisfying an applicable terminology binding. The requirements in the Terminology Bindings section continue to apply.
Obligations and mustSupport
As described in Consolidation Methodology, this specification uses obligations instead of mustSupport. Full definitions of the obligation codes are available in the obligation extension definition. The table below summarizes the baseline expectations for the obligation codes used by this guide:
| Mode | Code | Summary |
|---|---|---|
| Produced | populate-if-known | If the system represents the element internally - by storing, capturing, or displaying it - it must expose the data when it exists, unless regulation or privacy rules prohibit disclosure. The system is not required to support the element internally. |
| populate | The same expectation as populate-if-known, except the system must represent the element internally. Software enhancements may therefore be needed to conform. | |
| Consumed | no-error | The system must not fail or treat an instance as erroneous merely because the element is present. It may still apply business rules when processing the instance. |
| persist | The system must record the element's value in persistent storage. In this guide, the requirement depends on the associated production obligation: for a populate-if-known element, persistence is required only when the system handles that element internally. |
Parent and Child Element Obligations
P-Care assigns obligations independently to parent and child elements based on the requirements contributed by the source implementation guides. An obligation on a child element does not automatically establish an obligation on its parent.
For example, consider a profile where:
Observation.componenthas no obligation.Observation.component.value[x]has aSHALL:able-to-populateobligation.
The child obligation does not independently require an actor to create or support Observation.component. However, when the actor supports and populates the relevant component, it SHALL be capable of populating Observation.component.value[x] in accordance with the specified obligation.
FHIR cardinality and obligations remain independent. Cardinality determines which elements are structurally required or permitted in a conformant resource instance, while obligations describe actor-specific expectations for supporting or handling those elements. Applicable cardinality constraints continue to apply regardless of the assigned obligations.
Terminology Bindings
As described in Future Enhancements, this implementation guide has not yet adopted current or current-extensible bindings. For conformance testing, however, elements with required and extensible binding strengths are interpreted as current and current-extensible, respectively. These bindings therefore apply only to data captured in the EMR on or after the date the EMR first declared conformance with this guide.
This guide also uses additional bindings. When an element has multiple conformance bindings - through the primary binding and one or more additional bindings - instances are expected to satisfy all of them. Codes therefore need to map to each applicable value set. An extensible binding cannot be satisfied merely by sending a code from another binding unless the concept cannot be represented at any level of granularity in the extensibly bound value set.
Subscriptions
This guide requires support for the Subscription and SubscriptionTopic resources.
EMRs SHALL comply with the Subscription R5 Backport implementation guide.
Compliance requires more than exposing endpoints for the relevant resources. An EMR must also be able to send notifications to subscribers when qualifying events occur.
At present, the absence of standard SubscriptionTopics means this capability cannot be tested formally. Implementers SHOULD define their own subscription topics to demonstrate that the required infrastructure is in place. As noted in Future Enhancements, standard topics are expected in a future release.
Security
EMRs are responsible for protecting patient information and all other data they maintain. In addition to their standard safeguards, the following requirements apply:
- EMRs SHALL support EHR launch as defined in version 2.1.0 of the SMART App Launch specification, including an OAuth endpoint that supports the authorization protocol. (2.1.0 is used rather than 2.2.0 to align with HALO.)
- EMRs SHALL support inbound communications using SMART Backend Services.
- EMRs SHALL use TLS 1.2 for exchanges defined by this guide. They SHALL use only cryptographic algorithms recommended or deemed sufficient in the CCCS ITSP.40.062 specification specification and *SHOULD follow the document's additional guidance.