Service Requests Data Model

identifier : { Identifier } // Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller

id

uuid

M

Unique identifier of the current record

Ok

Approved 

instantiates : { uri } //Protocol or definition followed by this request.

-

No Implementation

Approved 

basedOn : [{ Reference(CarePlan | ServiceRequest | MedicationRequest) }] //Plan/proposal/order fulfilled by this request.

-

No Implementation

Approved 

replaces : [{ Reference(ServiceRequest ) }] //The request takes the place of the referenced completed or terminated request(s).

-

No Implementation

Approved 

requisition : { Identifier } //A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.

Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

requisition

string

М

Should be unique human readable number. See Human readable requisition number

Ok

Approved 

status : { code } //draft | active | suspended | completed | entered-in-error | cancelled RequestStatus (Required) The status of the order.

status

string

M

Active, Enterred In Error, Cancelled

Ok

Approved 

status_reason

codeable_concept

O

Implemented as a part of status_history

Ok

Approved 

explanatory_letter

string

O

Text explanation on why service request was cancelled or recalled.

Ok

Approved 

-

status_history

[ status_history ]

O

History of service request status changes if there were any. Contains status, code of a reason why status was set, date and time of change.

Ok

Approved

intent : { code } //proposal | plan | order + RequestIntent (Required) Whether the request is a proposal, plan, an original order or a reflex order.

intent

string

M

e-Health: by default Order 

Ok

Approved 

priority : { code } //routine | urgent | asap | stat RequestPriority (Required)Indicates how quickly the ServiceRequest should be addressed with respect to other requests.

priority

string

M

e-Health: by default Routine

Ok

Approved 

doNotPerform : { boolean } // Set this to true if the record is saying that the service/procedure should NOT be performed.

-

No Implementation

Approved 

category : { CodeableConcept } //Classification of service Service Request Category Codes (Example) A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").

category

codeable_concept

M

A code that classifies service which has to be provided to a patient

Ok

Approved 

code : { CodeableConcept } //  What is being requested/ordered Procedure Codes (SNOMED CT) (Example) A code that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested.

code

codeable_concept

M

e-Health: first release may not contain values in the dictionary

Ok

Approved 

orderDetail : { CodeableConcept } // Additional order information Service Request Order Details Codes (Example). Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have a order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

-

e-Health: no implementation because of no process at the moment

No Implementation

Approved 

subject : { Reference(Patient | Group| Location | Device) } // Individual the service is ordered for.  On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

subject

uuid

M

Patient for whoom the service is to be performed

Ok

Approved 

context : { Reference(Encounter | EpisodeOfCare) } // Encounter or Episode during which request was created. 

context

Reference (Encounter)

M

Encounter during which service request was created

Ok

Approved 

occurrence[x] : {  } //When service should occur

occurrence

occurrence

O

No Implementation

Approved 

occurrenceDateTime : { dateTime }

occurrence_date_time

date_time

O

The date and time when service should but does not have to occur. When creating service request one of should be specified: occurrence_date_time or occurrence_period.

Ok

Approved 

occurrencePeriod : { Period }

occurrence_period

period

O

Period when service should but does not have to occur. When creating service request one of should be specified: occurrence_date_time or occurrence_period.

Ok

Approved 

occurrenceTiming : { Timing }

No Implementation

Approved 

asNeeded[x] : {  } //  Preconditions for service SNOMED CT Medication As Needed Reason Codes (Example)  If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example "pain", "on flare-up", etc

No Implementation

Approved 

asNeededBoolean : { boolean }

asNeededCodeableConcept : { CodeableConcept }

authoredOn : { dateTime } Date request signed. 

authored_on

date_time

M

When the request transitioned to being actionable. In case of e-Health it is the date when request was signed.

Ok

Approved 

requester : { Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) } // The individual who initiated the request and has responsibility for its activation

requester_employee

Reference(Employee)

M

Employee who has created and signed service request

Ok

Approved 

requester_legal_entity

Reference(Legal_entity)

M

Organization (legal entity) which is responsible for service request 

Ok

Approved 

performerType : { CodeableConcept } // Performer role Participant Roles (Example) Desired type of performer for doing the requested service.

performer_type

codeable_concept

O

specialization to which the patient is referred (only for referrals for hospitalization it is mandatory, for others it cannot be indicated)
More information in:
https://www.hl7.org/fhir/servicerequest.html

Ok

Approved 

performer : { Reference(Practitioner | PractitionerRole | Organization | Patient | Device | RelatedPerson | HealthcareService | CareTeam) } // Requested perfomer. The desired perfomer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc

performer

O

reference to the organization where the patient is sent (only for transfer it is mandatory, for others it cannot be indicated)
More information in:
https://www.hl7.org/fhir/servicerequest.html

Ok

Approved 

location_reference

O

a link to the separated patient to whom the patient is referred (only for transfer it is optional, for others it cannot be indicated)

More information in:
https://www.hl7.org/fhir/servicerequest.html

Ok

Approved

reasonCode : [{ CodeableConcept }]// Procedure Reason Codes (Example). An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInformation

reason  

No Implementation

Approved 

reasonReference : [{ Reference(Condition | Observation | DiagnosticReport | DocumentReference) }] // Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInformation

reason_references

[Reference(Condition | Observation)]

O

e-Health: references only to Conditions and Observations.

Corresponds to Findings field in the form of referral which is currently used.

Ok

Approved 

insurance : { Reference(Coverage | ClaimResponse) } // Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service

-

No Implementation

Approved 

supportingInfo : [{ Reference(Any) }] // Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

supporting_info

[Reference(Episode of Care | Condition | Observation | Allergy Intolerance | Immunization | Diagnostic report)]

O

e-Health: references to Episode of Care, Condition, Observation, Allergy Intolerance, Immunization 

Corresponds to Treatments given, Clinical History, Documents accompanying referral fields in the form of referral which is currently used.

Ok 

Approved 

specimen : [{ Reference(Specimen) }] // One or more specimens that the laboratory procedure will use

-

No Implementation

Approved 

bodySite : [{ CodeableConcept }] // Location on Body SNOMED CT Body Structures (Example) (Anatomic location where the procedure should be performed. This is the target site)

No dictionary at the moment

No Implementation

Approved 

note : [{ Annotation }] // Comments

note

string

O

Any notes and comments made about the service request.

Ok

Approved 

patientInstruction : { string } // Patient or consumer oriented instructions

patient_instruction

string

O

Instructions in terms that are understood by the patient on how to be prepared for service obtaining

Ok

Approved 

relevantHistory : [{ Reference(Provenance) }] // Key events in the history of the reques

-

No Implementation

Approved 

-

permitted_resources

[Reference(EpisodeOfCare)|Reference(Diagnostic Report]

O

e-Health: used for giving access rights to view listed episodes to the future performer of the request

Ok

Approved/Renamed

-

used_by_employee

Reference(Employee)

O

e-Health: represents employee assigned to this referral

-

program

Reference(Program)

O

Medical program by which patient is getting prescribed service

New

-

used_by_legal_entity

Reference(Legal_enity)

O

Organization (legal entity) which is going to provide service by service request under a program. Not used for service requests without program.

New

-

expiration_date

string

M

format: datetime

New

-

program_processing_status

string

O

new, in queue, in progress, completed

New