This page defines the current resource contracts for laboratory and cervical screening requests, referrals, and episodic service orders. The profiles reuse standard FHIR workflow elements and introduce no generic local request parent.
PraxisLabServiceRequestDE is the reusable laboratory-order model.
PraxisCervicalScreeningServiceRequestDE narrows that model for cervical
screening.
| Concern | Contract |
|---|---|
| Stable order identity | identifier[placerOrderId] is required, typed as V2-0203 PLAC, and carries both system and value |
| Patient and ordering party | subject and requester |
| Intended laboratory | performer |
| Requested test | code, using LOINC or an issuer-controlled, versioned laboratory catalog |
| Indication and insurance | optional Must Support reasonReference and insurance |
| Specimen | optional ServiceRequest.specimen; screening narrows the target when present |
| Result correlation | standard DiagnosticReport.basedOn and Observation.basedOn |
| Specimen correlation | standard Specimen.request |
The order identifier namespace is controlled by its issuer. FHIR identity is
the (Identifier.system, Identifier.value) pair; PLAC identifies the role of
the identifier and is not a namespace.
The laboratory and screening proof Bundles are non-normative collection
examples. They demonstrate closed reference graphs and do not define document,
message, rendering, signature, or transport semantics.
The screening profiles use extensible bindings to selected LOINC codes and a required SNOMED CT specimen coding. The public package carries codes and canonical references without publishing restricted displays. Issuer-controlled local laboratory codes remain permitted by the extensible bindings.
PraxisReferralDE supports reusable incoming and outgoing referral records.
PraxisSociotherapyIndicationReferralDE derives from it because the record is
an indication referral. Hospital admission and patient transport use separate
thin ServiceRequest profiles because their performer targets and clinical
meaning differ.
| Shared element | Current rule |
|---|---|
| Order identity | required identifier[placerOrderId] with PLAC, system, and value; additional identifiers are allowed |
| Lifecycle | status is required and Must Support; intent is fixed to order for episodic orders |
| Ordered service | code is required; the binding remains open when no distributable authoritative catalog exists |
| Patient | subject is a required Patient reference |
| Ordering party | requester is required and targets PractitionerRole, Practitioner, or Organization |
| Intended performer | performer is required; each profile narrows the target set to its domain |
| Timing | authoredOn is required; occurrence[x] and priority are optional Must Support |
| Clinical context | reasonReference and supportingInfo carry structured indication, findings, documents, and medication context |
| Coverage | insurance is optional Must Support and targets Coverage |
PraxisHospitalAdmissionServiceRequestDE and
PraxisPatientTransportServiceRequestDE insert the same
PraxisServiceRequestCore RuleSet. PraxisSociotherapyIndicationReferralDE
inherits the same contract through PraxisReferralDE. A shared RuleSet is an
authoring consistency mechanism, not a new public profile.
The exact performer targets are intentional:
Organization or HealthcareService;Organization or HealthcareService;HealthcareService targets permitted by PraxisReferralDE.Form-specific semantics use a named public source when a distributable terminology exists. Otherwise the relevant element stays open for an authoritative or versioned local catalog. The IG does not infer national codes from paper labels and does not mirror unavailable issuer catalogs. Public terminology contracts are carried by this IG or referenced through public issuer packages. Protected displays and catalogs are installed separately by authorized runtime compositions.
The referral and episodic-order profiles are reusable record contracts. They do
not claim conformance to an official Annex 2b transport, form rendering,
attestation, signature, or payer-authorization envelope. Their proof Bundles are
collection examples only.
scripts/check-request-result-semantics.sh verifies the generated
differentials, cardinalities, Must Support flags, reference target sets, shared
RuleSet behavior, and proof-graph correlations. Negative validation cases are in
test/Profile/request-result-semantics.http.