Treat Health Connect medical records as a separate integration scope from fitness activity. A working steps reader does not establish that an app can safely interpret, request or release a vaccination-record workflow. The first deliverable is a partner data map and feasibility decision, not a broader permission request.
This is a product-engineering planning guide. It does not interpret medical records or recommend health decisions. Bring a fictional or redacted partner example, the proposed user task, responsible data owner and supported platform targets before discussing implementation.
Start with the task the medical record would serve
Android describes Medical Records as an extension using FHIR, with APIs for reading and writing and a dedicated user permission experience. The reviewed documentation also labels development and availability limitations. Recheck current feature support, SDK prerequisites and release eligibility for the exact integration rather than treating the presence of documentation as general availability.
Android: Health Connect Medical Records scope and limitations
For a synthetic partner request, the app already displays shared activity, while the partner proposes importing vaccination records. Ask who needs to see which field and for what action. “Show all health information together” does not explain the access boundary, supported semantics or responsibility for corrections. Narrow the milestone until the intended behavior can be evaluated.
Map the proposed resource without flattening its meaning
| Question | Activity example | Medical-record question |
|---|---|---|
| Data shape | Step interval and count | Which FHIR resource and profile? |
| Origin | Writing app and record ID | Which issuer and version? |
| Access | Activity permission | Which medical-record permission? |
| Correction | Update or delete import | How are amended resources reconciled? |
The table is conceptual and does not establish provider compatibility. FHIR is not a promise that every producer uses the same profiles, fields or optional values. Inspect an authorized sample and record which fields are required, absent or transformed. Preserve source identifiers and version meaning before designing a simplified card.
A string such as “completed” can have domain-specific meaning. Do not map it onto a generic fitness completion flag because the labels resemble each other. If the feature only needs a document handoff, evaluate that bounded workflow rather than introducing structured interpretation without a demonstrated need.
Keep access and presentation separate
A user granting an application access does not automatically authorize sharing the record with a coach, gym owner or external partner. Define the intended viewers and enforce their relationships in the application’s own access model. Include provenance and attachments in that boundary; metadata can still expose sensitive context.
The reviewed UltraFit360 source range checks fitness SDK availability. It does not demonstrate a FHIR reader, medical-record parser, release declaration or partner agreement. No medical-record API was called for this guide. Any future feasibility result must identify the actual dependency, supported feature check and accepted provider scope.
Agree a milestone that can end in a no-go decision
A useful discovery milestone reviews one fictional resource, validates its expected schema with the chosen tooling, traces permission and unavailable-feature states, and documents how correction and deletion would work. Record unresolved provider access and release questions as gates. Do not replace those gates with an attractive dashboard mockup.
Keep the conceptual figure labelled as a boundary map. It should show activity and medical-record paths meeting only at an explicitly proposed application decision. If prerequisites cannot be confirmed, the deliverable can be a documented no-go or a narrower handoff workflow. That is a concrete engineering result, and avoids promising compatibility before the partner contract exists.
Agree the correction owner with the proposed partner. If a resource is amended upstream, decide whether the application displays the new version, preserves an authorized historical snapshot or routes the discrepancy for review. A general fitness summary should not silently reinterpret an amended medical field. The feasibility record should name what the application will store and display, while leaving unsupported interpretation outside the milestone. That boundary can be reviewed even before any production connection is available.
Health connect integration fitness apps
Propose a bounded UltraFit360-related integration pilot with the partner system, intended users, data rights, owners and acceptance criteria; availability must be verified.
Can a fitness Health Connect integration automatically handle FHIR medical records?
No. Medical records introduce separate data models, permissions, feature availability and release questions that need their own feasibility scope.
Does FHIR guarantee two providers use identical fields?
No. Inspect the actual resource versions, profiles and optional data before mapping a partner feed.