ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Data Structure

Service Request

Object name: service_request

HL7
Name
Type
M/O
Description and constraints
HL7 vs eHealth comparison result
Status
identifier : { Identifier } // Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfilleriduuidM
Ok
-numberstringMShould be unique human readable number (for example see Human readable Medication request number)Ok
instantiates : { uri } //Protocol or definition followed by this request.-


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


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


No Implementation
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.requisitionuuid

Ok
status : { code } //draft | active | suspended | completed | entered-in-error | cancelled RequestStatus (RequiredThe status of the order.status
M
Ok
intent : { code } //proposal | plan | order + RequestIntent (RequiredWhether the request is a proposal, plan, an original order or a reflex order.intent
Me-Health: by default OrderOk
priority : { code } //routine | urgent | asap | stat RequestPriority (Required)Indicates how quickly the ServiceRequest should be addressed with respect to other requests.-

e-Health: no implementation because of no process at the momentNo Implementation
doNotPerform : { boolean } // Set this to true if the record is saying that the service/procedure should NOT be performed.-


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


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

e-Health: first release may not contain values in the dictionaryOk
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 momentNo Implementation
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


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


Ok
occurrence[x] : {  } //When service should occuroccurence


Ok
occurrenceDateTime : { dateTime }


(question) what types should be implemented


?
occurrencePeriod : { Period }


?
occurrenceTiming : { Timing }


?
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


(question) what is the purpose of this attribute


?
asNeededBoolean : { boolean }


?
asNeededCodeableConcept : { CodeableConcept }


?
authoredOn : { dateTime } Date request signed. authoredOn


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


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

performerType



this is a role, not a participation type. I.e. does not describe the task, but describes the capacity. For example, “compounding pharmacy” or “psychiatrist” or “internal referral”.Ok
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


(question) are requested performer and actual performer the same persons ? should we use another attribute for actual performer and leave current attribute for future use??
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 supportingInformationreason (question) 

e-Health: Only textual form (question) 

Corresponds to Reason for referral field in the form of referral which is currently used (question)

Ok
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 supportingInformationreasonReference[Reference(Condition | Observation)]

e-Health: references only to Conditions and Observations.

Corresponds to Findings field in the form of referral which is currently used (question)

Ok
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
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.supportingInfo[Reference(Episode of Care | Condition | Observation | Allergy Intolerance)]

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

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

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


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


(question) should we implement this attribute (seems that it should be used for procedural|diagnostic requests)?
note : { Annotation } // Commentsnotestring
e-Health: stringOk
patientInstruction : { string } // Patient or consumer oriented instructionspatientInstructionstring

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


No Implementation
-ExpirationDate

e-Heatth: used for automatic deactivation of unused referrals. Should be pre-configuredOk
-PermittedEpisodesOfCare[Reference(EpisodeOfCare)]
e-Heatth: used for giving access rights to view listed episodes to the future performer of the requestOk
  • No labels