Block Vote - Data Model Scope

input/pagecontent/datamodel.md

@@ -1,8 +1,8 @@
-At the core of the Standard Patient Health Record is the assumption that it will contain records in FHIR format, which provides a data model describing health history that has a pedigree of 30 years of industry experience and use in major EHRs.  
+The intention of the PHR FHIR Implementation Guide is to provide a standard mechanism for the communication of health records contained in a personal health record. FHIR provides a data model for health history with a pedigree of 30 years of industry experience and use in major EHRs, and is used here as the exchange and communication format.
 
-Loosely speaking, this data model contains all data that relevant to a patient's health, whether it be generated by clinicians in a hospital inpatient setting, by a specialist clinic or nursing home, or contributed the patient via gym fitness apps, nutrition tracking apps, and so forth.  The FHIR data model allows this flexibility, while still being informed by clinical learnings on how to code data with SNOMED, LOINC, ICD-10 and other vocabularies, how to organize data into resources, and how to apply region specific extensions and profiles.
+Loosely speaking, this data model encompasses all data relevant to a patient's health, whether it be generated by clinicians in a hospital inpatient setting, by a specialist clinic or nursing home, or contributed by the patient via gym fitness apps, nutrition tracking apps, and so forth. The FHIR data model allows this flexibility, while still being informed by clinical learnings on how to code data with SNOMED, LOINC, ICD-10 and other vocabularies, how to organize data into resources, and how to apply region specific extensions and profiles.
 
-When implementing a PHR, the following FHIR resources represent the surface area of what most EHRs, PHRs, and consumer medical devices will export.  While it is not the minimal amount of data necessary (many systems will begin implementation with a single resource type), it represents the minimum implementation needed to reasonably parse an arbitrary EHR or PHR record that one might receive from an external system.  Note that the FHIR specification itself contains some 120+ resources, many of which include clinical workflow, administrative, and public health functionality.  By contrast, the following model of ~36 resources is scoped to what a patient may receive via patient portals, consumer medical devices, health information exchanges, and the like.
+When implementing a PHR that conforms to this IG, the following FHIR resources represent the surface area of what most EHRs, PHRs, and consumer medical devices will export. While it is not the minimal amount of data necessary (many systems will begin implementation with a single resource type), it represents the minimum implementation needed to reasonably parse an arbitrary EHR or PHR record that one might receive from an external system. Note that the FHIR specification itself contains some 120+ resources, many of which include clinical workflow, administrative, and public health functionality. By contrast, the following model of ~36 resources is scoped to what a patient may receive via patient portals, consumer medical devices, health information exchanges, and the like.
 
 ### Model
 

input/pagecontent/datastorage.md

@@ -10,7 +10,7 @@ A useful way to think of data storage is in terms of slow-motion data transfer.
 
 As such, this implementation guide recommends that implementors treat storage in much the same way as over-the-wire data transfers.  
 
-- Systems MUST use FHIR data schemas to claim to be compliant with this IG.  
+- Systems MUST use FHIR data schemas when importing or exporting data to claim to be compliant with this IG.
 - Systems SHOULD use the same MIME types when possible.
 - Systems MAY treat directories as Bundle entries or NDJSON lines by default.
 

input/pagecontent/functionality.md

@@ -1,10 +1,10 @@
 A common question that comes up in designing a Personal Health Record is 'what features should it support?'.  This question has been discussed in great detail by past workgroup efforts, and we encourage implementors interested in guidance around which functionality to include to refer to [Personal Health Record System Functional Model](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88) with provides 93 pages and nearly 1800+ recommendations of functionalities that PHR vendors in the past have agreed ought to be included in a standard model.  
 
-However, for the purposes of this implementation guide, we are going to defer on the question of functionality, and take a more data-centric approach and consider the question in terms of importing/exporting records and data storage buckets. The general idea behind this document is that data will be added or removed from the PHR, either through granular API interfaces or bulk data import/export functions, we don't care which.  However, in either case, we will be using standard data schemas for how the data will be transmitted and stored.
+However, for the purposes of this implementation guide, we are going to defer on the question of functionality, and take a more data-centric approach and consider the question in terms of importing/exporting records and data storage buckets. The general idea behind this document is that data will be added or removed from the PHR, either through granular API interfaces or bulk data import/export functions, we don't care which.  However, in either case, we will be using standard data schemas for how the data will be transmitted and exchanged.
 
 For instance... rather than specify that the PHR must include medication reconciliation functionality, we recommend that a PHR must be able to consume a Continuity of Care Documents (CCD) received from a hospital in .sphr format, and to do so, the data should be specified with FHIR resources, which may happen to include MedicationStatement and other resources produced by a medication reconciliation module.  But whether or not the .sphr health record contains a medication reconcilitation or not is left completely up to the implementor.  The only requirement for conformance is that if the data is included in the .sphr file, it use FHIR data schemas.  
 
-In effect, this implementation guide does not specify what functionality should be included the PHR, but it does specify medical charting format that the record uses.  It's about the folder and record keeping, not the specific contents of the records themselves.  
+In effect, this implementation guide does not specify what functionality should be included in the PHR, but it does specify the format used when exchanging or communicating health records.  It's about the folder and record keeping, not the specific contents of the records themselves.
 
 ### PHR Functional Model (FHIR-ized)
 

input/pagecontent/recordkeeping.md

@@ -9,7 +9,7 @@ A useful way to think of data storage is in terms of slow-motion data transfer.
 
 As such, this implementation guide recommends that implementors treat storage in much the same way as over-the-wire data transfers.  We simply are defining file formats, rather than wire formats.  To this extent, we recommend the following principles when exporting data from their systems:
 
-- Systems MUST use FHIR data schemas to claim to be compliant with this IG.  
+- Systems MUST use FHIR data schemas when importing or exporting data to claim to be compliant with this IG.
 - Systems SHOULD use the `.phr` and `.sphr` MIME types when possible.
 - Systems MAY treat directories as Bundle entries or NDJSON lines by default.