This implementation guide defines several data sharing capabilities. Some behaviors are tightly defined and will work the same way in all environments (if all systems conform to this IG). However, in many cases, a degree of variation is allowed. This variation is necessary because of the breadth of types of implementation environments. For example:

• The participants involved in the exchange may vary - only Care Manager and Patient Engagement system, only Care Manager and Service Provider, or all three.
• The level of sophistication of the participants may vary - from a personal trainer using their phone, to a multi-billion-dollar EHR international vendor. This will influence what types of technical capabilities the systems will have - and how the systems prefer to operate.
• The level of infrastructure available may vary. Some environments may have shared registries available or shared persistence environments for patient and provider data, while others may rely on all data being stored in the same system.

This section walks through the design decisions already reflected in the IG, as well as those that remain to be selected by implementers, along with some guidance on how to make those decisions.

IG Design Decisions and Assumptions

This IG makes certain assumptions about the best way to meet the interoperability requirements of the physical activity area. This section summarizes those design decisions and the assumptions and rationale underlying them. The intent is to help better understand why this IG is designed as it is, as well as providing a foundation for feedback. Readers who believe alternative interoperability approaches should be used are invited to identify places where the assumptions or rationale leading to the current choices are faulty.

If you are only interested in design decisions that need to be made in the scope of your implementation in order to comply with this IG, rather than what decisions were made in the crafting of this IG, feel free to skip down to the Implementation Design Decisions section.

Data Exchange Mechanisms

This IG focuses on data sharing and uses several mechanisms to foster information sharing. In all cases, the specific mechanisms selected have been chosen based on guidance found in the new R5 Approaches to Exchanging FHIR Data section. The table below lists all the exchange mechanisms used by this guide, the circumstances in which the IG uses them, and the rationale for selecting the approach based on the context of this IG. The rationale includes the navigation of the decision tree found in the Approaches to Exchanging page.

Exchange Mechanism	Usage	Rationale
REST Create	Used by: Care Managers when making Tasks for Referral Management available to Service Providers when they store the Task on Service Provider systems. Patient Engagement systems and possibly Service Providers (if the Service Provider does not have its own FHIR RESTful store) when storing any of the Physical Activity Observations. For Service Providers it may also be used when storing Intervention Reports and possibly also new Goals or even Care Plans	RESTful create is appropriate because: The process is initiated by the data source. This aspect of the process varies. If the data source stores the record on their own system, then subscription would apply and retrieval would be guided by the data consumer. However, where the data is to be stored on the data consumer, then the data consumer is not involved in configuring when or how updates are received. There is expected to be a direct connection between the data source and consumer. (This IG does not presently support the use of intermediaries.) The data source directs which record is to be updated and how. Each Task is stored as an independent entity, not as a group. There is no expectation of multiple record changes being initiated at once. This is a new record.
REST Update	Used by: Either Service Providers or Care Managers to update Tasks for Referral Management. Care Managers to cancel the Task, if necessary, when stored on the Service Provider, and Service Providers to update the status and/or add Task.outputs when they store the Task on Care Managers. Patient Engagement systems to set status and/or add Task.outputs to Tasks for Patients. Patient Engagement systems and possibly Service Providers or Care Managers to update Goals and Care Plans that are not stored locally.	RESTful update is appropriate because: The process is initiated by the data source. The data consumer is not involved in configuring when or how updates are received. There is expected to be a direct connection between the data source and consumer. (This IG does not presently support the use of intermediaries.) The data source directs which record is to be updated and how. Each Task is stored as an independent entity, not as a group. There is no expectation of multiple record changes being initiated at once. We are updating an existing record. While the changes could be handled as a patch, this feature is not widely supported and the instances being changed are relatively small, meaning that the whole record will be changed.
Subscription with Query	Used by: Service Providers to be notified that a new Tasks for Referral Management exists when the Care Manager system stores the Task on their own system, or for Care Managers to be notified that the Task has been updated when they have stored it on a Service Provider system. Patient Engagement systems to be notified that a new Task for Patients exists.	Subscription is appropriate because: The process is initiated by the data source, in that it triggers the record change that causes information to need to flow. The data consumer is involved in configuring when or how updates are received because the data is not stored on their system and they might not always be available for it to be pushed to them. The key determiner of whether this approach is used instead of polling is whether subscription is supported. This IG has made the determination that mandating support for at least limited subscriptions is reasonable and the complexity of doing so is more than compensated by the reduced bandwidth expectations as compared to polling. To leverage simpler (and less secure) subscription mechanisms such as email notifications, the data itself will not be pushed as part of the subscription notification. Note that this means that search is always also used. See further discussion below in the Subscriptions vs. polling
Synchronous RESTful Search	Used by: Patient Engagement systems whenever retrieving information from Care Managers or Service Providers Care Managers or Service Providers when retrieving information from each other.	RESTful synchronous search is appropriate because: The process is initiated by the data consumer, as it decides what information it is interested in retrieving and when. There is expected to be a direct connection between the data source and consumer. (This IG does not presently support the use of intermediaries.) There is not expected to be human intervention involved in the data retrieval process. CDS hooks cards would not be an appropriate retrieval mechanism. The data will already exist at the time it is retrieved. The focus of the change is retrieving resources. At the time of retrieval, there might be multiple resources to retrieve - and the resource ids of the desired records will not always be known. The exchange is not about retrieving the history of any particular resource. The desired data should be returnable with an ad-hoc query. The data can reasonably be retrieved using RESTful search. The data should be retrievable in real time, so there is no need for asynchronous.

Participant Representation

In FHIR, any person (or animal) who is involved in creating, performing, ordering, or otherwise participating in an action will be identified as one of three resources:

• Patient - which represents a recipient of care, regardless of the type of care or whether the care is medical in nature
• RelatedPerson - which represents someone who acts on the basis of their personal relationship with the patient (relative, friend, roommate, etc.)
• Practitioner - which represents someone who is acting in their professional capacity.

A range of additional participants are also possible, including Devices, Organizations, Care Teams, and HealthcareServices. All these potential participants are explored below.

Electronic Sharing with Patients

The term 'patient' may also be foreign to some of the implementers of this implementation guide. Personal trainers and gyms may think of those they work with as "clients", "customers", "guests", or some similar term. FHIR's use of the word 'patient' and the Patient resource in no way excludes use by such systems. The user interfaces for systems should continue to use whatever terminology is appropriate in their business, regardless of the names of the underlying FHIR objects.

Like the Gravity Social Determinants of Health (SDOH) IG, this IG requires support for electronic data sharing with patient systems. Not all patients will have such systems - or even devices capable of accessing or running such systems. Even with access to the systems, not all patients will choose to make use of them. Care can still be provided in such cases, and the IG ability to share information between Care Managers and Service Providers will still be beneficial. As well, patient circumstances may change over time, meaning that data that might not have been accessed originally might be accessed at some point in the future when capability and/or interest change.

The requirement to share data with patients has two justifications:

• Current U.S. regulations mandate the provision of electronic data to patients in interoperable formats.
• Applications with an awareness of goals, referrals, plans, and other data can better support patients as they make lifestyle changes that will result in increased physical activity.

In addition to patients having access to read data stored on other systems, there is also value in them being able to share information with other systems and even update data residing in those other systems. See further discussion on this in the Permissions section below.

Patient Data Management

This IG allows for direct data capture by patients (or their caregivers) both manually and using their devices. Quite often, this data may, at least initially, be stored on patient devices such as phones or tablets. In some cases, it might also find its way into personal health record (PHR) type systems. One of the IG design questions was whether to have patient systems expose their own endpoint to allow local data to be pulled by Care Manager or Service Provider systems.

For now, this IG presumes that patient-facing systems will not expose their own FHIR server endpoint. All data transfer will be pushed from the Patient Engagement system to whatever other systems require it. The project made this decision because:

• Most patient storage devices do not support exposing FHIR server endpoints.
• The market for personal health records that could offer such functionality is immature and not widely used by the patient community.
• There are standard mechanisms for patients to discover the endpoints of their care providers and gain secure access to those servers through apps. There are no similar standard mechanisms for EHRs to discover and securely access patient-centric endpoints.

PHRs and other patient-facing applications that have their own storage capabilities are welcome to share how they have overcome barriers around endpoint discovery and authorization and/or present evidence of more widespread use. In the future, the project may extend this IG to support architectures where systems can 'pull' data from patient-facing systems rather than always having it pushed.

Patient Caregivers

While giving patients the ability to access, and potentially manipulate, data in other systems is valuable, the reality is that not all patients will be able to do this on their own behalf. Minors as well as those with cognitive or other limitations may be unable to use Patient Engagement systems on their own. In such situations, patients may rely on family members, neighbors, or others to interact with the systems on their behalf. In this IG, such individuals are represented using the RelatedPerson profile. Support for this resource is strongly encouraged but is not mandated as the clientele of some providers may not justify the additional application complexity of supporting users who are acting "on behalf of" someone else, including the consent, access permissions and other considerations that go along with supporting access by anyone other than the patient themselves. (In such cases, it is possible that patients will resort to account sharing, though this may force them to expose more data than they might otherwise wish to.)

Providers

As previously mentioned, Practitioner is used to capture the participation of an individual who is acting in their professional capacity. Note that practitioners need not be clinical, or even licensed (though regulations, payers, and other policies may set limits around the scope of practice of different types of individuals based on training, etc.). Practitioner encompasses administrative staff, even taxi drivers or others employed completely outside the scope of healthcare. So long as the individual is doing what they do as their "job" (even if in a volunteer/internship position), they are a Practitioner.

Referencing Practitioners can be done using one of two profiles - US Core Practitioner and US Core PractitionerRole. The former allows referring to a provider irrespective of their role or who they are working for. The latter also allows specifying the organization they were working on behalf of at the time of the action and/or the functional role they were taking on at the time. In some cases, if the specific individual is not known or relevant, it might be only the role and/or organization that are populated and no individual Practitioner will be referenced by the PractitionerRole.

In this IG, where it is appropriate to reference providers, there is usually a choice as to whether to send Practitioner or PractitionerRole. However, in some cases, the US Core IG has limited participations to Practitioner only, in which case, this IG enforces the same restriction. Where available, implementers should generally send PractitionerRole when organization or role is known and relevant.

In some cases, the source system may only know the name and identifier of the individual and not have a stand-alone Practitioner/PractitionerRole resource. In this case, it is sufficient to use a logical reference specifying just the identifier and display (name) elements.

Provider Identity

For insurance to cover referred services, some form of credentialing and registration of individual users will also likely be needed. What expectations payers will have are not yet firmly established. However, it is likely that registration with professional bodies such as The US Registry of Exercise Professionals will be needed. As well, the individual Practitioners and/or Organizations will need to register for a National Provider Identifier (NPI) with the Centers for Medicare and Medicaid Services (CMS). While practitioners can leverage this IG without having an NPI, they will typically not be able to submit insurance claims based on HIPAA regulations. The Physical Activity Alliance will work with CMS to reduce barriers to applying for NPIs for exercise professionals that are not directly affiliated with healthcare organizations.

Provider Groups

In FHIR, a collection of providers acting together can be represented in three different ways:

• Organization represents a collection of individuals who can act collectively. This does not need to be a legal entity. It can be used to represent anything from an international company down to a small department or team.
• CareTeam represents a collection of individuals where each has a specific function within the team that needs to be called out. Essentially, a CareTeam is an organization that breaks out who is responsible for what.
• HealthcareService is used to represent the delivery offerings of a specific organization at a specific site, including availability time and possibly other details about accepted coverage, etc.

For the sake of simplicity, this IG has chosen to only support Organization when representing clinics, hospitals, fitness centers, and other provider groupings. These will be expressed using the US Core Organization profile. Future releases of this IG may set expectations for use of some of the other resources, depending on how relevant provider groupings are managed in registries and what implementers find most useful.

Devices

Many of the activity-based and time-based Observations supported by this profile are most likely to be captured using devices. It is simply not practical for patients to manually count steps, determine average heart rate, or estimate calories burned. The Observation resource has an element that allows capturing information about the device used in performing a measurement. Future releases may mandate support for this element. However, to keep implementation as simple as possible, for now there is no expectation to capture information about the devices used in data capture.

Data Storage Location

One of the key questions that drives much of the architecture is where systems will store data. Specifically, where are Tasks, CarePlans and Goals, and even Observation data stored? Do copies of the records exist in each system, or are they maintained in only one? If only one, is it the system that originally created them or a different system? Considerations in making these decisions include the following:

• Is there a need for a consistent view of the data - where each system involved has the same understanding?
• Does one system have sole authority to make changes to the record, or at least to control who changes the record?
• Will changes to the record typically originate more on one system than another?
• Does one system have a need for the most up-to-date information about a record more than others?

In this IG, for all the resources shared, the preference, and sometimes the requirement, is that there be a single authoritative copy of the information. For referrals and the tasks that manage their execution, this is a firm requirement for legal and payment reasons. For goals, care plans and conditions, it is a strong expectation to avoid patient confusion and ensure all participants are working in alignment. For observations, having duplication is less problematic.

The storage decisions that are 'locked down' by this IG are as follows:

• The Service Requests that represent a referral authorization will always be stored on the Care Manager system of the practitioner that created the referral. Only the organization that created the referral can change it. Status changes, including marking the referral as 'complete' are determined by the ordering system - even if the performing system thinks a referral is complete, the requester might disagree.
• Conditions will also always be stored on the Care Manager system, as only clinical systems are typically authorized to create official 'diagnoses'. As well, other systems cannot update these records.
• Based on the patient data decisions above, information such as observation values might be stored on Patient Engagement systems, but this data will not be accessible by other systems. This means that physical activity observations captured by patients will need to be cloned when being shared with Care Managers or Service Providers.

Discussion of storage locations that may vary by implementation environment are discussed below.

Questionnaires

The Gravity SDOH IG this guide draws from relies on QuestionnaireResponses as the initial means of capturing assessment answers for a patient's SDOH needs. The key answers are then extracted into observations and a draft Condition generated if the answers in the response indicate that an SDOH issue is likely. Questionnaires are foundational in the Gravity space because there are many social determinants, and the questions that need to be asked to accurately identify whether an SDOH is evolving and which may be different in different populations.

This IG has opted not to assert the same dependency on the use of Questionnaires as a data gathering technique for assessment information. The base measures used to assess physical activity only contain four questions, and one of those is calculated by multiplying two of the other answers. The guidelines for 'appropriate' activity levels by age are extremely simple. The measures are also quite stable, as are the guidelines. As a result, the need for rapid evolution and tight control over data capture is less. To minimize the implementer complexity around supporting automated extraction of QuestionnaireResponses into Observations and Conditions, the decision was made to not require this architectural approach. Systems are still free to use it if they find it valuable.

Handling Intermediaries

In the Gravity SDOH IG, support is provided for intermediary systems to operate between the ordering systems and the service delivery systems. These are labeled coordination platforms. They take general or broad referrals and break them down into smaller referrals divvied out to service providers with the necessary expertise to undertake specific tasks. They might also handle the process of trying to find the most appropriate service provider to handle a particular referral, having a deeper knowledge of the available service agencies than the ordering provider might.

For now, this IG has not introduced a similar concept. The reasons for this are:

• The complexity of the referrals envisioned in the physical activity space is significantly less than it is for social determinants of health.
• There are not (yet?) well developed agencies in the physical activity space who typically take on a coordination role.
• For this initial release of the implementation guide, there is a desire to minimize complexity where possible.

If there is a need for intermediaries in a particular implementation environment, they will typically be able to accomplish their objectives by implementing both the Care Manager and Service Provider interfaces. When interacting with a Care Manager, they will behave as a Service Provider and vice versa.

REST vs. Messaging

Some of the other HL7 IGs that have been defined also provide support for referral submission and management. These environments have opted to use messaging rather than RESTful exchange. The use of messaging makes sense in environments where there is no mechanism to support securely searching for additional data when needed. In that situation, there is no choice but to define in advance exactly what data might need to be shared and to package it all up and transmit it at once. However, in the physical activity case, the primary data holder will be EHRs and, due to U.S. regulations, almost all such systems provide a FHIR interface to allow searching for data. REST is a preferred interoperability mechanism over messaging because it is lighter-weight and requires less customization. It also allows participants to adapt their exchanges more easily as requirements evolve. Therefore, this IG therefore follows the Gravity SDOH IG approach of leveraging REST for referral management.

Subscription vs. Polling

As described in the Gravity SDOH IG, there are two common mechanisms for allowing a remote system to monitor for new and changed resources on another system - polling and subscriptions. This IG has opted to standardize on only the subscription mechanism. The email and SMS-polling mechanisms do not require any software capabilities on the part of the Service Provider and are relatively simple to be implemented by Care Managers. In more sophisticated environments, systems can use the Web-hook mechanism.

The polling mechanism can place a significant load on Care Managers, and this outweighs the slight savings involved in avoiding the need to develop subscription capabilities.

To keep the subscription process as simple as possible, this IG does not mandate support for electronic creation or maintenance of subscriptions. While this can be done, systems are also free to handle set-up of subscriptions manually as part of the registration process.

Transactions and Batch

The FHIR specification allows client systems to submit multiple creates or updates using the batch or transaction mechanism. There may be situations where it is attractive to submit multiple observations, or even a care plan and associated goals with a single call, and implementers are free to take advantage of these mechanisms where both sides provide support. However, in the interest of simplicity, this IG does not currently set any conformance expectations around the use of these capabilities.

Note that, for most systems, it will be possible to make multiple calls to the same FHIR server in parallel, which may reduce some of the drivers for the batch/transaction interactions.

Resource Categories

Many of the profiles used in this resource mandate or require support for the use of specific category element values. Some of these expectations are inherited from US Core where they help EHRs determine which internal tables a given instance is associated with when the same FHIR resource might correspond to multiple internal EHR concepts. This IG adds additional expectations related to the Physical Activity category code. The intention behind this additional code is to provide a simple mechanism for Care Managers (and possibly Service Providers) to distinguish resources that are relevant to physical activity from others. This would then provide a basis for easily filtering what sorts of records should be disclosed to Service Providers who are exercise professionals. Additional records (e.g. ACE inhibitor medications, hypertension or diabetes conditions, height and weight observations, etc.) that are also relevant and appropriate for exercise professionals could be similarly tagged.

Is this a useful mechanism for managing access control? Would implementers prefer that we drop this expectation and instead drive access control by some other mechanism?

Implementation Design Decisions

This section of the IG covers the various architectural considerations that are not nailed down as part of the IG design and where variability across implementations is expected (or at least allowed for). Implementations will need to make choices amongst these options based on the implementation environment, or in some cases, may need to support multiple mechanisms.

As the community becomes more mature and we learn more about what implementers can and cannot be expected to do, it is likely that at least some of the optionality currently supported here will be reduced. Feedback is welcome on areas where optionality is felt to be unnecessary or problematic.

Implementation Storage Decisions

As noted in the section on storage above, there are a few situations where the location in which certain resources are stored and maintained may vary based on environment. This section discusses those situations:

Storing Referral Tasks

There are two options for where tasks seeking referral fulfillment:

1. Create the Task on the Service Provider system.
2. Create the Task on the Care Manager.

The first option is preferred because the Task will primarily be manipulated by the Service Provider, and they have the most urgent need to understand the 'current' state of the fulfillment process. However, not all Service Providers will have a FHIR server endpoint that can host the relevant Tasks. For this reason, there are two distinct Capability Statements defined - one for 'full' service providers which have FHIR server capability and would be responsible for storing the Task, and one for 'light' service providers which would be notified of relevant tasks created on the Care Manager and then would use search to retrieve and update to change status and add outputs as necessary.

Storing Goals and Plans

Goals and plans might be managed by either Service Providers or Care Managers, but regardless of where they are managed could be updated by any of the systems. The choice of which system should store should be driven by who initiates the goals and plans and who will be taking the lead in maintaining those records. Depending on the circumstance, it could be either. Obviously, a Service Provider can only take responsibility for the records if it has a FHIR endpoint, so this is limited to 'full' service providers.

Storing Observations

Unlike referrals, plans, and goals, observations are rarely changed once created, so there are fewer negative consequences to the same records existing on multiple systems. As well, as discussed in the general section on storage above, the primary sources of observational data - Patient Engagement systems - are not expected to have FHIR endpoints. They might well capture data locally, but if it is going to be shared, it will need to be pushed to the Service Provider and/or Care Manager systems. Which one(s) receive the data, and which observation types get pushed, depends on what information the systems want to see. Some might not want to receive data at all and will rely on verbal conversation with the patient to evaluate progress. Others might be only interested in the base measures but not want all of the supporting measures. Some systems will be interested in everything. Because of this variability, patient engagement systems should be configurable to allow a patient to identify which system(s) should receive which information (provided, of course, that the patient is comfortable with sharing any of it).

Permissions for Changing and Creation

Historically, goal and care plan information have resided on the system of whomever created them and were revised solely by the users of that system. However, interoperable interfaces now mean that it is possible for other systems (and therefore other users) to be involved in the maintenance of these resources. For example, a patient, one of their care-givers, and/or an exercise professional might update a plan originally created by a physician. The same "multi-user participation" approach could occur with artifacts created in a service provider system. However, supporting multiple authors adds some complexity and requires some implementation decisions:

• What external systems (and users) can make changes? Are patients and their caregivers allowed to make changes? Can clinicians make changes to records held by exercise professionals, or vice versa?
• What operations are permitted? Can external systems create care plans and/or goals, or only update them? (Typically, records are not deleted - statuses are changed instead. Certainly, deletion by external systems would be uncommon.)
• What data elements can be changed? Can the nature of the goal or plan itself be changed, or are changes limited to adding comments and/or updating status?
• Are the rules different based on who created the record? For example, would a patient or service provider have full edit privileges for plans or goals they created themselves on a Care Manager, but more restrictions on records that were created by a practitioner within the Care Manager organization.

These decisions will be driven by organizational policy as well as provider comfort levels. However, suggested elements to support updating include at least the following: CarePlan.status, CarePlan.period, CarePlan.note, Goal.lifecycleStatus, Goal.achievementStatus, Goal.note.

Certain elements will typically never be allowed to be change - even if being updated by the same system that originally created the record - e.g. the patient, the creating provider, etc. In situations where the data elements cannot be updated, if the data is incorrect the solution is to update the original record's status to "entered-in-error" and then create a new record with the updated information.

Task as a Means of Communication

Tasks for referral management are the mechanism that Care Managers use to communicate with Service Providers. At a minimum, there is a need to communicate the following:

• A practitioner is asking an exercise professional/organization to fulfill a referral. (Task.status='requested')
• The exercise professional/organization has accepted or rejected that request for fulfillment. (Task.status='accepted'/'rejected')
• The exercise professional/organization considers their work to be completed. (Task.status='completed')

However, there is additional information that can be shared. Systems can use Task.status to communicate additional information as shown in the notes section of the profile. As well, they can use Task.statusReason and Task.note to convey additional information. Task.statusReason is set by whichever system sets the status (Care Manager for 'cancelled' and Service Provider for 'rejected', 'on-hold', or 'failed'). Task.note might be populated by either system. Finally, there is the intervention report linked to by Task.output which is created by the Service Provider. Typically, this is done at the completion of the referral, but in some cases the draft version of the report might be shared early, or even multiple reports created over time.

There is an additional element defined on Task - Task.businessStatus - that can also be used to convey information about the progress of a Task. In this release, this element has not been marked as mustSupport, though its use is not prohibited. It would generally only be set by the Service Provider.

If implementers have found a need for Task.businessStatus and/or Task.note, please communicate that to the design team using the "propose a change" link or on the project chat.fhir.org stream. Future release of this implementation guide may set expectations around the use of these elements if there are clear implementation requirements.

The design decision here is around how much communication is necessary or appropriate. Some Care Managers may have little interest beyond acceptance and completion, while others may find value in progress updates for each visit. Service Providers may not have a workflow design, bandwidth, and/or funding to provide any information beyond the minimum, or they might be well-positioned to document and share progress on a regular basis. This IG does not set specific expectations for how much information should be communicated or in what circumstances. For now, such decisions are up to the participants in the exchange and may be negotiated accordingly.

Registries

Communication between Care Managers and Patient Engagement systems is somewhat straight-forward because, based on US regulation, EHRs already need to have a mechanism of registering and authenticating patients and enabling them to communicate with their systems, typically using OAuth as defined by SMART on FHIR patient-mediated authentication. However, establishing a connection between care managers and Service Providers is somewhat more challenging as there will often not be a direct personal relationship between care manager and service provider.

Establishing interoperability will mean exchanging endpoint locations, establishing trust (having each system's authorization engine grant appropriate privileges to relevant users of the other system), and putting in place necessary legal frameworks, such as affiliate agreements to allow sharing of data and ensuring that data shared is subject to appropriate protections.

In the short term, relationships between Care Managers and Service Providers will need to be manually negotiated and established. Implementers will need to work to create business and legal arrangements with other interested parties who have undertaken the work to comply with this standard and are able to create or receive referrals. In the intermediate term, organizations may be able to take advantage of the anticipated national provider registry leveraging the FAST Directory Query IG standard to discover eligible Practitioners and Organizations and leverage the shared legal framework to establish connection automatically without a need for point-to-point negotiation.

Resolving Identity

Unlike CareTeams, Practitioners, PractitionerRoles, Organizations and HealthcareServices as discussed above, there typically will not be a shared registry of Patients or Related Persons available to reference. There is also not (yet?) a single shared patient identifier that systems can use to reliably convey the identity of these individuals. However, there will be a need for Care Managers, Service Providers and Patient Engagement systems to recognize patient and related person records referenced in other systems with the equivalent records in their own system to ensure that duplicate records are not accidentally created.

Given the absence of a reliable cross-system identifier, matching will need to be performed based on demographics. This IG does not set expectations for how systems perform matching, beyond setting standards for what demographic information must be shared. There are a wide variety of approaches that account for variations in spelling, transposition of portions of birth date, changes in identifying information such as gender, etc. Each implementation will need to determine a set of criteria that sufficiently reduces both the risk of an incorrect match, as well as the failure to match appropriately - and thus risk the creation of a duplicate record.

Additional exchange

This IG defines specific profiles on information directly related to physical activity that are not well defined in other IGs. However, it is likely that the stakeholders involved in helping a patient improve their physical activity will find information useful above and beyond what is in this guide. Information on past injuries, physical or cognitive limitations, certain medications, certain concomitant health conditions, etc. can all influence decisions around appropriate and safe therapy. Therefore, implementers of this IG might well support searching for resources that do not fall within the profiles defined here. The choice of what additional data is appropriate (and authorized) will need to be negotiated based on circumstance as well as based on patient consent. See the Security and Privacy page for more discussion.