Skip to content
OPRP

Reference source · 0.1.0-dev.11

standards-references.md

docs/standards-references.md · Download original file

# Open Patient Record Protocol Standards References

Use these primary sources when drafting OPRP. Referenced standards supply building blocks; they do not define OPRP's new encrypted message profile, authority governance, migration contract, or implementation claims. Pin adopted versions and record deviations in the specification.

## Clinical data and authorization

- [FHIR R4 HTTP interactions](https://hl7.org/fhir/R4/http.html) defines existing REST, conditional update, and transaction behavior to evaluate for the Host interface.
- [FHIR R4 provenance](https://hl7.org/fhir/R4/provenance.html) provides a model for recording who created or revised clinical content.
- [JWT RFC 7519](https://www.rfc-editor.org/rfc/rfc7519.html) supplies the access-token representation. OPRP defines issuance policy and required claims separately.
- [SMART 2.2.0 Backend Services](https://hl7.org/fhir/smart-app-launch/STU2.2/backend-services.html) is a reference for obtaining tokens under preauthorized access without user approval at runtime. [SMART scopes](https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html) provide scope conventions to evaluate. OPRP does not mandate App Launch or assert complete SMART conformance by adopting selected conventions.
- [FHIR R4 RelatedPerson](https://hl7.org/fhir/R4/relatedperson.html) and [FHIR R4 Consent](https://hl7.org/fhir/R4/consent.html) provide candidate representations for relationships and consent. A relationship record alone does not establish legal or delegated authority.
- [FHIR R5 subscriptions](https://hl7.org/fhir/R5/subscriptions.html) provides topic-based event notification. [Subscriptions Backport 1.1.0](https://hl7.org/fhir/uv/subscriptions-backport/) provides a versioned path for earlier FHIR releases.
- [OAuth DPoP](https://www.rfc-editor.org/rfc/rfc9449.html) provides an existing proof-of-possession pattern. Its use does not automatically supply OPRP's chosen post-quantum authentication profile.
- [OAuth refresh RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html#section-6) supplies refresh-exchange conventions. [OAuth security RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.14) supplies refresh-protection guidance. OPRP separately defines the approved access period and compatible post-quantum requester binding.

## Discovery and trust

- [WebFinger RFC 7033](https://www.rfc-editor.org/rfc/rfc7033.html) supports account-based service discovery over HTTPS. OPRP must define its own service relation and authenticated bindings.
- [Well-Known URIs RFC 8615](https://www.rfc-editor.org/rfc/rfc8615.html) supplies the registration framework for service metadata paths.
- [Internet PKI RFC 5280](https://www.rfc-editor.org/rfc/rfc5280.html) supplies the certificate-chain model to evaluate for credentials. Organization verification and post-quantum algorithm profiles require additional rules.

## Message security

- [NIST FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) specifies ML-KEM for establishing a shared secret used by symmetric cryptography. Review published errata and implementation requirements.
- [NIST FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) specifies ML-DSA signatures. Review published errata and implementation requirements.
- [HTTP Message Signatures RFC 9421](https://www.rfc-editor.org/rfc/rfc9421.html) provides message-component signing conventions. A concrete OPRP profile must specify coverage, replay behavior, and post-quantum algorithms.
- [Digest Fields RFC 9530](https://www.rfc-editor.org/rfc/rfc9530.html) provides HTTP content-digest conventions to evaluate with message signatures.
- [HPKE RFC 9180](https://www.rfc-editor.org/rfc/rfc9180.html) provides a useful KEM, key-derivation, and authenticated-encryption framework. Do not assume its original algorithm set supplies the required post-quantum suite; evaluate the exact adopted construction.
- [TLS 1.3 RFC 8446](https://www.rfc-editor.org/rfc/rfc8446.html) supplies the HTTPS transport baseline. [Hybrid TLS key agreement RFC 10024](https://www.ietf.org/ietf-ftp/rfc/rfc10024.html) is relevant additional transport protection, separate from the required OPRP payload layer.

## US deployment context

- [HHS medical-record retention guidance](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-require-covered-entities-to-keep-medical-records-for-any-period/index.html) explains that HIPAA's Privacy Rule does not itself set medical-record retention periods and that state laws generally govern retention. The US profile needs deployment-specific policy mapping.
- [US patient access information](https://healthit.gov/patient-access-to-health-records/) supplies context for patient access rights; it does not establish that OPRP displaces provider recordkeeping obligations.
- [HHS personal representatives](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html) describes authority-dependent representation and parental-access exceptions relevant to the US profile.
- [HHS health-care power of attorney](https://www.hhs.gov/hipaa/for-professionals/faq/does-having-health-care-power-attorney-allow-access-patients-medical-mental-health-records-under-hipaa/index.html) explains that effectiveness can be immediate or conditional, depending on the document and applicable authority.

## Verification status

Sources were inspected during project discussion on October 1, 2026. The proposed baseline is selected for implementation planning, not represented as the newest available release of every dependency. Recheck exact versions, errata, algorithm registration, and platform support during the design and cryptography milestones.

## Expanded resource and SDK implementation references

The October 1, 2026 increment used [FHIR R4 interactions](https://hl7.org/fhir/R4/http.html), [Condition](https://hl7.org/fhir/R4/condition.html), [AllergyIntolerance](https://hl7.org/fhir/R4/allergyintolerance.html), [MedicationStatement](https://hl7.org/fhir/R4/medicationstatement.html), [Encounter](https://hl7.org/fhir/R4/encounter.html), [Procedure](https://hl7.org/fhir/R4/procedure.html) and [Immunization](https://hl7.org/fhir/R4/immunization.html) as profile references. The handwritten validator implements only the declared subset; using R4 fields does not establish exhaustive FHIR or US Core conformance.

[Microsoft ML-KEM](https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.mlkem?view=net-10.0) and [ML-DSA](https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.mldsa?view=net-10.0) expose platform support detection. Both native support flags are false on the tested macOS runtime. The prototype .NET SDK uses an explicitly selected local PQClean provider; this does not claim universal native .NET PQ availability.

## Visibility references

The October 2, 2026 increment uses [FHIR R4 security labels](https://hl7.org/fhir/R4/security-labels.html), [Meta](https://hl7.org/fhir/R4/resource.html#Meta) and [summary/SUBSETTED guidance](https://hl7.org/fhir/R4/http.html#summary). [OPRP visibility](visibility.md) defines the narrower exact-label policy, partial-view restrictions and cache generation mechanism; it does not implement every handling obligation or jurisdictional rule.

## External clinical validation references

The October 2, 2026 profile increment uses [R4 profiling](https://hl7.org/fhir/R4/profiling.html), the published [US Core 9 catalogue](https://hl7.org/fhir/us/core/STU9/profiles-and-extensions.html) and [HL7 validator 6.10.4](https://github.com/hapifhir/org.hl7.fhir.core/releases/tag/6.10.4). The pinned US target is an OPRP test choice; deployment/certification version selection remains separate. See [external clinical validation](external-clinical-validation.md) for structure-only evidence, disabled terminology and unresolved transitive locking.