FHIR IG analytics| Package | hl7.ehrs.uv.phrsfmr2 |
| Resource Type | Requirements |
| Id | Requirements-PHRSFMR2-S.3.6.json |
| FHIR Version | R5 |
| Source | https://build.fhir.org/ig/HL7/phrsfm-ig/Requirements-PHRSFMR2-S.3.6.html |
| URL | http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.3.6 |
| Version | 2.0.2 |
| Status | active |
| Date | 2026-01-28T20:43:35+00:00 |
| Name | S_3_6_Manage_PHR_Data_Import_and_Export |
| Title | S.3.6 Manage PHR Data Import and Export (Function) |
| Authority | hl7 |
| Description | Allow the PHR Account Holder to manage the import to and export of data from a PHR-S. |
| Purpose | A PHR Account Holder needs to prescribe how data is exchanged with other systems including how data is imported to the PHR-S, and the parameters for data export (e.g., who, when, or the extent of data). Some import and export functions may be one-time events; other exchanges, for example, may occur at regular intervals (such as via a subscription service). The PHR Account Holder should be able to determine the information or data that he/she will accept into the PHR. The system should record the acknowledgement or refusal of data sent to the Account Holder’s PHR-S. Use of exported data should be constrained according its intended and permitted purpose of use (e.g., as described in the PHR-S manufacturer's Terms of Service and Terms of Use agreements). Example(s): The PHR Account Holder may desire to inform her General Practitioner that the PHR Account Holder has received a proposed dietary regimen from a Registered Dietitian / Nutrition specialist. The PHR Account Holder may also desire to send a copy of the proposed nutrition care plan to the General Practitioner. |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
A PHR Account Holder needs to prescribe how data is exchanged with other systems including how data is imported to the PHR-S, and the parameters for data export (e.g., who, when, or the extent of data). Some import and export functions may be one-time events; other exchanges, for example, may occur at regular intervals (such as via a subscription service). The PHR Account Holder should be able to determine the information or data that he/she will accept into the PHR. The system should record the acknowledgement or refusal of data sent to the Account Holder’s PHR-S. Use of exported data should be constrained according its intended and permitted purpose of use (e.g., as described in the PHR-S manufacturer's Terms of Service and Terms of Use agreements).
Example(s): The PHR Account Holder may desire to inform her General Practitioner that the PHR Account Holder has received a proposed dietary regimen from a Registered Dietitian / Nutrition specialist. The PHR Account Holder may also desire to send a copy of the proposed nutrition care plan to the General Practitioner.
| S.3.6#01 | SHOULD |
The system SHOULD provide the ability to exchange PHR Account Holder data content with another PHR system. |
| S.3.6#02 | SHOULD |
The system SHOULD provide the ability to exchange PHR Account Holder data content with other systems. |
| S.3.6#03 | SHOULD |
The system SHOULD provide the ability to exchange PHR Account Holder data content with other systems. |
| S.3.6#04 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to determine entities from which data may be imported into the PHR-S. |
| S.3.6#05 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to determine entities to which data may be exported from the PHR-S. |
| S.3.6#06 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to exchange information with an entity on a one-time basis. |
| S.3.6#07 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to exchange information with an entity on a recurring basis. |
| S.3.6#08 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to annotate incoming information. |
| S.3.6#09 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to render a notification (i.e., an acknowledgment) of the receipt or the refusal to receive information that was sent from another system. |
| S.3.6#10 | SHALL |
The system SHALL conform to TI.1.5 (Non-Repudiation) to promote provenance regarding professionally-sourced clinical information. |
FHIR
FHIRsmith{
"resourceType": "Requirements",
"id": "PHRSFMR2-S.3.6",
"meta": {
"profile": [
"http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/FMFunction"
]
},
"language": "en",
"text": {
"status": "extensions",
"div": "<!-- snip (see above) -->"
},
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
"valueCode": "normative"
},
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
"valueCode": "ehr"
}
],
"url": "http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.3.6",
"version": "2.0.2",
"name": "S_3_6_Manage_PHR_Data_Import_and_Export",
"title": "S.3.6 Manage PHR Data Import and Export (Function)",
"status": "active",
"date": "2026-01-28T20:43:35+00:00",
"publisher": "EHR WG",
"contact": [
{
"telecom": [
{
"system": "url",
"value": "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description": "Allow the PHR Account Holder to manage the import to and export of data from a PHR-S.",
"purpose": "A PHR Account Holder needs to prescribe how data is exchanged with other systems including how data is imported to the PHR-S, and the parameters for data export (e.g., who, when, or the extent of data). Some import and export functions may be one-time events; other exchanges, for example, may occur at regular intervals (such as via a subscription service). The PHR Account Holder should be able to determine the information or data that he/she will accept into the PHR. The system should record the acknowledgement or refusal of data sent to the Account Holder’s PHR-S. Use of exported data should be constrained according its intended and permitted purpose of use (e.g., as described in the PHR-S manufacturer's Terms of Service and Terms of Use agreements).\r\n\r\nExample(s): The PHR Account Holder may desire to inform her General Practitioner that the PHR Account Holder has received a proposed dietary regimen from a Registered Dietitian / Nutrition specialist. The PHR Account Holder may also desire to send a copy of the proposed nutrition care plan to the General Practitioner.",
"statement": [
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-01",
"label": "S.3.6#01",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability to exchange PHR Account Holder data content with another PHR system.",
"satisfiedBy": [
"https://hl7.org/fhir/uv/bulkdata/"
]
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-02",
"label": "S.3.6#02",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability to exchange PHR Account Holder data content with other systems."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-03",
"label": "S.3.6#03",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability to exchange PHR Account Holder data content with other systems."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-04",
"label": "S.3.6#04",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to determine entities from which data may be imported into the PHR-S."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-05",
"label": "S.3.6#05",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to determine entities to which data may be exported from the PHR-S."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-06",
"label": "S.3.6#06",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to exchange information with an entity on a one-time basis."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-07",
"label": "S.3.6#07",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to exchange information with an entity on a recurring basis."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-08",
"label": "S.3.6#08",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to annotate incoming information."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-09",
"label": "S.3.6#09",
"conformance": [
"SHOULD"
],
"conditionality": false,
"requirement": "The system SHOULD provide the ability for the PHR Account Holder to render a notification (i.e., an acknowledgment) of the receipt or the refusal to receive information that was sent from another system."
},
{
"extension": [
{
"url": "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean": false
}
],
"key": "PHRSFMR2-S.3.6-10",
"label": "S.3.6#10",
"conformance": [
"SHALL"
],
"conditionality": false,
"requirement": "The system SHALL conform to TI.1.5 (Non-Repudiation) to promote provenance regarding professionally-sourced clinical information."
}
]
}