|
|
| Regel 107: |
Regel 107: |
| | You can find examples of FHIR-instances (filled-in FHIR profiles) in the Nictiz GitHub repository: [https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/lab/3.0.0 <nowiki>Lab exchange HL7-mappings repository</nowiki>]. | | You can find examples of FHIR-instances (filled-in FHIR profiles) in the Nictiz GitHub repository: [https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/lab/3.0.0 <nowiki>Lab exchange HL7-mappings repository</nowiki>]. |
| | | | |
| − | ==FHIR Profile Package== | + | == Transactions == |
| − | All use cases in this specification depend on the same set of FHIR profiles. The table below lists profiles that represent applicable zibs for laboratory result information exchange.
| + | === Health professional orders lab tests and receives results === |
| | + | ==== Involved actors ==== |
| | + | {| style="text-align: left;" cellpadding=5px; |
| | | | |
| − | {{NoteBoxNictizR4Package|p1=nictiz.fhir.nl.r4.labexchange|v1=3.0.0-beta.2|p2=nictiz.fhir.nl.r4.nl-core|v2=0.8.0-beta.1|p3=nictiz.fhir.nl.r4.zib2020|v3=0.6.0-beta.2}}
| + | |- style="color: white; background-color: #e7844b;" |
| | + | ! Transaction group || Transaction || Actor || System role code || FHIR CapabilityStatement |
| | | | |
| − | {| class="wikitable" style="min-width:90%;"
| + | |- style="background-color: #fcf0e9;" |
| − | |-style="background-color:#1F497D; color:white; font-weight:bold;" | + | | rowspan="2" | Send laboratory results based on a request |
| − | |FHIR Profile | + | | Send laboratory results based on a request || Client || LAB-LAS || rowspan="2" |{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-SendReceive|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.4|title=Lab2Healthcare_Results_SendReceive}} |
| − | |FHIR Resource
| |
| − | |style="min-width:150px;"|Based on zib (EN)
| |
| − | |- | |
| − | | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-LaboratoryTestResult|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.6.0-beta.2|title=nl-core-LaboratoryTestResult}}
| |
| − | | Observation | |
| − | | rowspan="3" | LaboratoryResult | |
| − | |-
| |
| − | | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-LaboratoryTestResult.Specimen|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.6.0-beta.2|title=nl-core-LaboratoryTestResult.Specimen}} | |
| − | | Specimen
| |
| − | |-
| |
| − | | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-LaboratoryTestResult.Specimen.Source|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.6.0-beta.2|title=nl-core-LaboratoryTestResult.Specimen.Source}}
| |
| − | | Device
| |
| − | |-
| |
| − | | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.6.0-beta.2|title=nl-core-Patient}}
| |
| − | |Patient
| |
| − | |Patient
| |
| − | |-
| |
| − | | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|title=nl-core-HealthcareProvider-Organization}}
| |
| − | |Organization
| |
| − | |HealthcareProvider
| |
| − | |}
| |
| | | | |
| − | =Actors involved=
| + | |- style="background-color: #fcf0e9;" |
| − | {| class="wikitable"
| + | | Receive laboratory results || Server || LAB-LAO |
| − | ! colspan="2" style="text-align:left;" | Persons
| |
| − | ! colspan="2" style="text-align:left;" | Systems
| |
| − | ! colspan="2" style="text-align:left;" | FHIR Capability Statements
| |
| − | |- | |
| − | ! style="text-align:left;" |Name
| |
| − | ! style="text-align:left;" |Description
| |
| − | ! style="text-align:left;" |Name
| |
| − | ! style="text-align:left;" |Description
| |
| − | ! style="text-align:left;" |Name
| |
| − | ! style="text-align:left;" |Description
| |
| − | |-
| |
| − | | rowspan="2" | Lab Professional
| |
| − | | rowspan="2" | The user of a LIS
| |
| − | | rowspan="2" | LIS
| |
| − | | rowspan="2" | Laboratory information system
| |
| − | | [[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-RetrieveServe|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.1|title=CapabilityStatement: Lab2Healthcare-Results-RetrieveServe}}
| |
| − | | Retrieve [LAB-LRR]/serve [LAB-LRB] lab results requirements. A LIS is only expected to serve results in the context of Lab2zorg.
| |
| − | |-
| |
| − | | [[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-SendReceive|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.1|title=CapabilityStatement: Lab2Healthcare-Results-SendReceive}}
| |
| − | | Send [LAB-LRS]/receive [LAB-LRO] lab results requirements. A LIS is only expected to send results in the context of Lab2zorg.
| |
| − | |-
| |
| − | | rowspan="2" | Healthcare professional
| |
| − | | rowspan="2" | The user of a XIS | |
| − | | rowspan="2" | XIS
| |
| − | | rowspan="2" | (Any) Healthcare information system
| |
| − | | [[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-RetrieveServe|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.1|title=CapabilityStatement: Lab2Healthcare-Results-RetrieveServe}}
| |
| − | | Retrieve [LAB-LRR]/serve [LAB-LRB] lab results requirements. A XIS may both retrieve results and serve copies of results in the context of Lab2zorg.
| |
| − | |-
| |
| − | | [[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-SendReceive|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.1|title=CapabilityStatement: Lab2Healthcare-Results-SendReceive}}
| |
| − | | Send [LAB-LRS]/receive [LAB-LRO] lab results requirements. A XIS may both send copies of results and receive (copies of) results in the context of Lab2zorg. | |
| − | |}
| |
| | | | |
| − | =Use cases=
| + | |+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Abbreviations: LAB = Laboratorium, LAS = Laboratoriumresultaat antwoord sturend (systeem), LAO = Laboratoriumresultaat antwoord ontvangend (systeem).'' |
| − | ==Health professional orders lab tests and receives results==
| |
| − | ===Introduction===
| |
| − | As defined in the functional design, a health professional can order laboratory tests after seeing a patient. Some laboratory tests such as blood gases and EBV serology consist of multiple subtests and are ordered together as one test (a panel). When the order has been received and performed by the laboratory, the results including interpretation are sent to the XIS of the requesting health professional together with the order and patient details. The main FHIR resource to express the laboratory test results is a {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/lu-LaboratoryTestResult-DiagnosticReport|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.2|title=DiagnosticReport}}.
| |
| − | | |
| − | ===Health professional orders lab tests===
| |
| − | ''This transaction is not yet implemented.''
| |
| − | | |
| − | ===Health professional receives lab results resulting from a request ===
| |
| − | | |
| − | ====Actors====
| |
| − | {| class="wikitable" "cellpadding="10"
| |
| − | ! style="text-align:left;"| '''Transaction group'''
| |
| − | ! style="text-align:left;"| '''Transaction'''
| |
| − | ! style="text-align:left;"| '''Actor'''
| |
| − | ! style="text-align:left;"| '''Role'''
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;" rowspan="2"|Send laboratory results (PUSH)
| |
| − | |style="background-color: white;vertical-align:top;"|Send laboratory results
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatSturend Systeem [LAB-LRS]
| |
| − | |style="background-color: white;vertical-align:top;"|Send lab results to the LAB-LRO
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;"|Receive laboratory results
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatOntvangend Systeem [LAB-LRO]
| |
| − | |style="background-color: white;vertical-align:top;"|Respond to received lab results from the LAB-LRS
| |
| | |} | | |} |
| | | | |
| − | ====Invocations==== | + | === Health professional retrieves lab results === |
| − | =====LAB-LRS: request message===== | + | ==== Involved actors ==== |
| − | The LIS (LAB-LRS) sends lab results and relevant context information using a HTTP POST method on the endpoint of the XIS of the health professional that requested the laboratory test (LAB-LRO)
| + | {| style="text-align: left;" cellpadding=5px; |
| | | | |
| − | ======Trigger Events====== | + | |- style="color: white; background-color: #e7844b;" |
| − | This message is invoked when the LIS needs to send laboratory results to a XIS.
| + | ! Transaction group || Transaction || Actor || System role code || FHIR CapabilityStatement |
| | | | |
| − | ======Message Semantics====== | + | |- style="background-color: #fcf0e9;" |
| − | A [http://hl7.org/fhir/r4/documents.html FHIR document] is used for this use case. This approach is chosen because laboratory results resulting from a request include details about the patient and order, next to the actual laboratory results. In this context, the resources sent by the LIS should be considered a discrete package that is transmitted as-is. It is up to the receiving XIS to extract and persist the resources from the document that it considers relevant.
| + | | rowspan="2" | Retrieve laboratory results (PULL) |
| | + | | Retrieve laboratory results request || Client || LAB-LRR || rowspan="2" |{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-RetrieveServe|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.4|title=Lab2Healthcare_Results_RetrieveServe}} |
| | | | |
| − | A FHIR document is sent by performing a HTTP POST command to the Bundle endpoint as shown:
| + | |- style="background-color: #fcf0e9;" |
| | + | | Retrieve laboratory results response || Server || LAB-LRB |
| | | | |
| − | <pre>POST [base]/Bundle</pre>
| + | |+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Abbreviations: LAB = Laboratorium, LRR = Laboratoriumresultaat raadplegend (systeem), LRB = Laboratoriumresultaat beschikbaarstellend (systeem).'' |
| − | | + | |} |
| − | The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|document}} that has a Composition resource as the first resource. The Composition resource should conform to the Composition profile {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/lu-Composition|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.2|title=Composition}}. In this context, a Composition is solely used to send the laboratory results across in a document. Therefore, the Composition only contains one section with a reference to the DiagnosticReport. The DiagnosticReport contains information on the structure of all the resources in the document. All resources referenced by the DiagnosticReport SHALL be present in the Bundle. These resources SHALL conform to the matching profile(s) listed in the [[#FHIR_Profile_Package|profile]] table. That table contains profiles that represent applicable zibs for laboratory result information exchange.
| |
| − | | |
| − | ======Identification======
| |
| − | | |
| − | Resources SHALL have a stable identifier in the {{fhir|.identifier}} element for all resources if such an identifier exists in the underlying data. Not all data, like individual results, are currently known to have identifiers in all source systems, but when they exist they are essential and where they do not exist yet they SHOULD be considered. Having stable identification is essential in detection of duplicates and potential clinical decision making issues deriving from duplicates. For more information on dealing with identifiers, see the [[FHIR:V1.0_FHIR_IG_R4#Usage_of_the_.id.2C_.identifier_and_.fullUrl_elements_in_FHIR_instances|general FHIR IG]].
| |
| − | | |
| − | The {{fhir|.identifier}} in {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/lu-LaboratoryTestResult-DiagnosticReport|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.2|title=DiagnosticReport}} SHALL at least be a Placer Order ID assigned by the placer (ordering application). The Placer Order ID identifies an order uniquely among all orders from a particular ordering application. In this case, a XIS (LAB-LRO). The {{fhir|.identifier}} MAY additionally be populated with a Filler Order ID, assigned by the filler (fulfilling/receiving application). This identifier is the order number associated with the filling/receiving application and uniquely identifies all orders from the particular filling application. In this case a LIS (LAB-LRS).
| |
| | | | |
| − | The placer/filler order identifiers, specimen identifiers, container identifiers, and observation identifiers are all identifiers issued by an information system, XIS or LIS. Identification always requires specification of the identification system that the identifier is from, and per the central [[FHIR:V1.0_FHIR_IG_R4#When_is_.identifier_expected.3F|FHIR IG]] guidance on identifiers this SHALL be an [[Hoofdpagina#Object_IDentifiers_.28OIDs.29|OID]]. There are a number of ways to get an OID, but most systems are expected to already have (access to) one:
| + | ==== Search parameters ==== |
| | + | {| style="text-align: left;" cellpadding=5px; |
| | + | |- style="color: white; background-color: #e7844b;" |
| | + | ! FHIR Search Parameter || Description || FHIR Resource || Example |
| | | | |
| − | * Your organization may have a UZI Registry Registration Number or URA. See also guidance on [[Hoofdpagina#Object_IDentifiers_.28OIDs.29|OIDs]]. The URA OID ''2.16.528.1.1007.3.3'' has a one to one correspondence with uri ''<nowiki>http://fhir.nl/fhir/NamingSystem/ura</nowiki>'', but when you get to the system level this correspondence no longer holds. Hence the use of OIDs. Example:
| + | |- style="color: white; background-color: #eda778;" |
| − | ** The system ID: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.3.[URA]</nowiki> {{fhir|value}} [XIS/LIS]
| + | ! colspan="4" | Retrieve laboratory results (Observation search) |
| − | ** Order Numbers: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.3.[URA].1</nowiki> {{fhir|value}} 11111111
| |
| − | ** Specimen IDs : {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.3.[URA].2</nowiki> {{fhir|value}} 22222222
| |
| − | ** Container IDs: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.3.[URA].3</nowiki> {{fhir|value}} 33333333
| |
| − | * Your system may have UZI Registry System ID under OID ''2.16.528.1.1007.3.2''. The system for the UZI System ID has a one to one correspondence with uri ''<nowiki>http://fhir.nl/fhir/NamingSystem/uzi-nr-sys</nowiki>'', but applying to sub systems like order numbers etc. looks the same as the URA:
| |
| − | ** The system ID: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.2</nowiki> {{fhir|value}} [UZI System ID]
| |
| − | ** Order Numbers: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.2.[UZI System ID].1</nowiki> {{fhir|value}} 11111111
| |
| − | ** Specimen IDs : {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.2.[UZI System ID].2</nowiki> {{fhir|value}} 22222222
| |
| − | ** Container IDs: {{fhir|system}} <nowiki>urn:oid:2.16.528.1.1007.3.2.[UZI System ID].3</nowiki> {{fhir|value}} 33333333
| |
| − | * Your lab system may have a three digit LABID that you may use as your base for all different kind of identifiers the system may issue. Example:
| |
| − | ** The system ID: {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4</nowiki> {{fhir|value}} [LABID]
| |
| − | ** Order Numbers: {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4.[LABID].1</nowiki> {{fhir|value}} [LABID]11111
| |
| − | ** Specimen IDs : {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4.[LABID].2</nowiki> {{fhir|value}} [LABID]22222
| |
| − | ** Container IDs: {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4.[LABID].3</nowiki> {{fhir|value}} [LABID]33333
| |
| | | | |
| − | Other common applicable identification systems exist. The main characteristic that the OID strategy SHALL have is ''persistent globally unique''. There SHALL NOT ever be more than one object carrying the same identification, i.e. the same combination of identification system and identification value. If you run out of numbers, and have to restart your numbering because labs typically deal with max 8 characters in their IDs due to barcode constraints, you can still distinguish two identification values 11111111 from one another by changing the identification system value, e.g.:
| + | |- style="background-color: #fcf0e9;" |
| | + | | patient || Constrain results to a specific patient context || Observation || <pre>GET [base]/Observation?patient=Patient/123</pre> |
| | | | |
| − | * {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4.[LABID].1</nowiki> {{fhir|value}} [LABID]11111
| + | |- style="background-color: #fcf0e9;" |
| − | * {{fhir|system}} <nowiki>urn:oid:2.16.840.1.113883.2.4.3.11.61.4.[LABID].4</nowiki> {{fhir|value}} [LABID]11111
| + | | category || Restrict search to laboratory observations || Observation || <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory</pre> |
| | | | |
| − | While logic is required in creating OIDs, from the point of coming into existence they are plain strings. No semantics may be inferred from individual nodes in an OID. LIS A may have order numbers under a system ending in .1 in DiagnosticRepost.identifier, and LIS B may have specimen IDs under a system ending in .1 in Specimen.identifier. XIS A may even go as far as having a node for production versus test, followed by the node for order numbers, e.g. ending in .1.1 and .2.1.
| + | |- style="background-color: #fcf0e9;" |
| | + | | code || Filter by laboratory test code (LOINC/NHG) || Observation || <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&code=http://loinc.org|14683-7</pre> |
| | | | |
| − | System administrators SHALL keep record of the OIDs they issue to avoid inadvertent reuse. System administrators MAY delegate record keeping and maintenance, e.g. to a more central part in a larger organization they are part of.
| + | |- style="background-color: #fcf0e9;" |
| | + | | date || Filter results based on observation date || Observation || <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&date=gt2022-03-12&date=lt2022-06-07</pre> |
| | | | |
| − | ======Expected Actions======
| + | |- style="color: white; background-color: #eda778;" |
| − | On receipt of the {{fhir|FHIR Document}} submission, the XIS (LAB-LRO):
| + | ! colspan="4" | Retrieve latest laboratory results ($lastn operation) |
| − | * SHALL process creation of the Bundle;
| |
| − | * SHALL decide which, if any, of the resources in the Bundle are relevant for individual processing;
| |
| − | ** The XIS MAY update pre-existing information with the incoming information;
| |
| − | ** The XIS MAY keep its pre-existing matching resources as-is;
| |
| − | * SHALL be aware that the latest information for a lab result is available in the latest FHIR document that has not been followed up by any other FHIR document;
| |
| − | ** Please note that even a final document MAY be followed up by a document containing corrections.
| |
| − | * SHALL respond using a HTTP code and body that honors the [https://build.fhir.org/exchanging.html Prefer header] and interaction. See [[FHIR:V1.0_FHIR_IG_R4#Handling_errors|FHIR IG Handling Errors]] for response options in case of errors.
| |
| | | | |
| − | ======Must Support====== | + | |- style="background-color: #fcf0e9;" |
| | + | | $lastn || Retrieve most recent lab results using the $lastn operation || Observation || <pre>GET [base]/Observation/$lastn?max=5&category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&code=http://loinc.org|14683-7</pre> |
| | | | |
| − | The main FHIR resource to express the laboratory test results is a DiagnosticReport. Both the LIS and the XIS shall take into account that the profile contains ''Must Support'' flags. The base [http://hl7.org/fhir/r4/profiling.html#mustsupport|FHIR Must Support] guidance requires specifications to define exactly the support expected for profile elements labeled ''Must Support''.
| + | |- style="color: white; background-color: #eda778;" |
| | + | ! colspan="4" | Retrieve related resources |
| | | | |
| − | For querying and reading the DiagnosticReport profile, ''Must Support'' on any profile data element SHALL be interpreted as follows:
| + | |- style="background-color: #fcf0e9;" |
| | + | | _include || Include linked resources (Specimen, Patient, Organization) in the response bundle || Observation || <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&_include=Observation:specimen&_include=Observation:patient&_include=Observation:performer</pre> |
| | | | |
| − | * The LIS (LAB-LRS) SHALL be capable of populating all data elements as part of the query results.
| + | |+ style="align: bottom; caption-side: bottom; text-align: left;" | ''All queries are executed in the authenticated patient context as per MedMij Afsprakenstelsel; no patient search parameters are used.'' |
| − | * The XIS (LAB-LRO) SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
| |
| − | **In other words the XIS (LAB-LRO) SHOULD be capable of displaying the data elements for human use or storing it for other purposes.
| |
| − | * In situations where information on a particular data element is not present and the reason for absence is unknown, the LIS (LAB-LRS) SHALL NOT include the data elements in the resource instance returned as part of the query results.
| |
| − | * The XIS (LAB-LRO) SHALL interpret missing data elements within resource instances as data not present in the LIS (LAB-LRS).
| |
| − | * The LIS (LAB-LRS) SHOULD send the reason for the missing information if the reason for the absence of data is known.
| |
| − | ** Refer to the section on ''Missing Data'' for guidance on how to handle missing data.
| |
| − | * The XIS (LAB-LRO) SHALL be able to process resource instances containing data elements asserting missing information.
| |
| − | | |
| − | =====LAB-LRO: response message=====
| |
| − | The XIS (LAB-LRO) returns an HTTP Status code appropriate to the processing outcome.
| |
| − | | |
| − | ======Trigger Events======
| |
| − | The XIS (LAB-LRO) completed processing of the send laboratory results message.
| |
| − | | |
| − | ======Message Semantics======
| |
| − | The XIS (LAB-LRO) SHALL return a {{fhir|201}} Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version. The XIS (LAB-LRO) SHOULD also return an {{fhir|ETag}} header with the {{fhir|versionId}} (if versioning is supported) and a {{fhir|Last-Modified}} header.
| |
| − | | |
| − | ======Expected Actions======
| |
| − | The XIS/LIS (LAB-LRS) processes the results according to application-defined rules. The most basic of those rules would include marking the transaction as sent/processed successfully or flag a need for action like resending or contacting the LAB-LRO.
| |
| − | | |
| − | ======Handling Errors======
| |
| − | The XIS (LAB-LRO) may be unable to accept a Bundle due to errors or because of technical or business rules. Refer to the [[FHIR:V1.0_FHIR_IG_R4#Handling_errors#Handling_errors|Handling Errors section]] in the FHIR IG for more information.
| |
| − | | |
| − | ==Health professional retrieves lab results==
| |
| − | ===Introduction===
| |
| − | Healthcare professionals need to be able to retrieve laboratory results directly from a lab (LIS) or a secondary healthcare provider (XIS). Different healthcare professionals may have different needs and/or authorizations. The core FHIR specification offers support for a lot of use cases. This specification only outlines options for the identified scope and associated minimal expectations. As such it is ''not'' intended to be limiting to said expectations. Servers SHALL use the CapabilityStatement to advertise their implementation and clients SHOULD use this as means to discover the servers capabilities as per the FHIR specification, as well as publish their own capabilities. <nowiki>[</nowiki>[http://hl7.org/fhir/r4/http.html#3.1.0 FHIR RESTful]<nowiki>]</nowiki> / <nowiki>[</nowiki>[http://hl7.org/fhir/r4/capabilitystatement.html#notes CapabilityStatement]<nowiki>]</nowiki>.
| |
| − | | |
| − | The identified use cases within the scope of this implementation guide are very broad:
| |
| − | | |
| − | * Get latest X results for one or more specific {{fhir|Observation.code}}s
| |
| − | * Get latest X results for any {{fhir|Observation.code}}s
| |
| − | * Get results on/before/after date X
| |
| − | * Get results on/before/after date X for one or more specific {{fhir|Observation.code}}s
| |
| − | * Get results based on the {{fhir|Observation.identifier}}
| |
| − | | |
| − | Each server SHALL perform filtering based on the patient, and results associated with the request context and patient identification search parameters, so only the records are returned that the requesting party is authorized for. Example expectations are that any ordering provider will have access to results related to his orders, and any requesting party interested in medication related results only has access to those.
| |
| − | | |
| − | A special word of caution about volume. It has been proven hard to impossible to define an optimum on how much history should be supported. For example some genetic tests are done once at age 15, and are still valid at age 80. Returning ''all'' results for someone age 80 could take an enormous toll on both server and client and is seldom relevant. Clients are therefore encouraged to be as specific as possible, by using both {{fhir|code}} and/or {{fhir|date}} and/or [https://www.hl7.org/fhir/r4/search.html#count {{fhir|_count}}] whenever possible. Servers SHOULD implement [https://www.hl7.org/fhir/r4/search.html#count {{fhir|_count}}], and SHOULD implement an OperationOutcome that informs the client of a partial result set when the total number exceeds what a server will handle.
| |
| − | | |
| − | ===Actors===
| |
| − | {| class="wikitable" "cellpadding="10"
| |
| − | ! style="text-align:left;"| '''Transaction group'''
| |
| − | ! style="text-align:left;"| '''Transaction'''
| |
| − | ! style="text-align:left;"| '''Actor'''
| |
| − | ! style="text-align:left;"| '''Role'''
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve laboratory results (PULL)
| |
| − | |style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatRaadplegend Systeem [LAB-LRR]
| |
| − | |style="background-color: white;vertical-align:top;"|Send a query to the LAB-LRB to retrieve lab results
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatBeschikbaarstellend Systeem [LAB-LRB]
| |
| − | |style="background-color: white;vertical-align:top;"|Respond to a query from the LAB-LRR to retrieve lab results
| |
| | |} | | |} |
| | | | |
| − | ===Invocations=== | + | === Health professional sends lab results to other health professional === |
| − | ====LAB-LRR: request message====
| + | ==== Involved actors ==== |
| − | The request message represents an HTTP GET parameterized query from the XIS (LAB-LRR) to the XIS/LIS (LAB-LRB).
| + | {| style="text-align: left;" cellpadding=5px; |
| − | | |
| − | =====Trigger events=====
| |
| − | When the healthcare professional wants to obtain laboratory results, it issues a retrieve laboratory results request message.
| |
| − | | |
| − | =====Message semantics=====
| |
| − | The XIS (LAB-LRR) executes an HTTP GET conforming to the FHIR [http://hl7.org/fhir/r4/http.html RESTful] and [http://hl7.org/fhir/r4/search.html search] specification against the XIS/LIS's Observation endpoint.
| |
| − | | |
| − | * Laboratory results are all under the {{fhir|.category}} ''observation'', using query parameter {{fhir|category}} as token.
| |
| − | * Requesting data for a specific {{fhir|.subject}} is done using query parameter {{fhir|patient}} as reference, or on some network infrastructures with an authorization token. The FHIR query parameter type [https://www.hl7.org/fhir/r4/search.html#reference reference] can take on many forms.
| |
| − | ** If you know what the {{fhir|Patient.id}} is, e.g. from previous interactions with the same endpoint, you may use:
| |
| − | *** {{fhir|<nowiki>patient=[id]</nowiki>}}
| |
| − | *** {{fhir|<nowiki>patient=[type]/[id]</nowiki>}}
| |
| − | *** {{fhir|<nowiki>patient=[url]</nowiki>}}
| |
| − | ** If you don't know what the {{fhir|Patient.id}} is, but you know the {{fhir|Patient.identifier}}, e.g. the Burgerservicenummer (BSN), you may use:
| |
| − | *** {{fhir|<nowiki>patient:identifier=[system]|[value]</nowiki>}}
| |
| − | * Requesting laboratory results of a specific type is done using query parameter {{fhir|code}} as token.
| |
| − | * Requesting laboratory results of a specific date (range) is done using query parameter {{fhir|date}} as token.
| |
| − | * Requesting laboratory results for a specific business identifier is done using query parameter {{fhir|identifier}} as token.
| |
| − | | |
| − | '''Basic query syntax'''
| |
| − | <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory{&patient=Patient/[id] | &patient:identifier=[system]|[value]}{&[parameter(s)]&_include=[resource(s)]}</pre>
| |
| − | | |
| − | '''Examples'''
| |
| − | | |
| − | Parameter values have not been uri escaped in these examples for readability. This is likely necessary in practice.
| |
| − | | |
| − | {{Collapse top|Get all lab results of type 14683-7 (LOINC) for patient with BSN 111222333}}
| |
| − | <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | {{Collapse top|Get all lab results of type 14683-7 (LOINC) for patient with BSN 111222333 since March 12, 2022}}
| |
| − | <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7&date=gt2022-03-12</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | {{Collapse top|Get all lab results of type 14683-7 (LOINC) for patient with BSN 111222333 since March 12, 2022 but before June 7, 2022}}
| |
| − | <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7&date=gt2022-03-12&date=lt2022-06-07</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | {{Collapse top|Get all lab results of type 14683-7 (LOINC) and/or 3583 (NHG) for patient with BSN 111222333}}
| |
| − | <pre>GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7,https://referentiemodel.nhg.org/tabellen/nhg-tabel-45-diagnostische-bepalingen|3583</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | {{Collapse top|Get latest lab result of type 14683-7 (LOINC) for patient with BSN 111222333}}
| |
| − | <pre>GET [base]/Observation/$lastn?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7</pre>
| |
| − | {{Collapse bottom}} | |
| − | | |
| − | {{Collapse top|Get latest 5 lab results of type 14683-7 (LOINC) for patient with BSN 111222333}}
| |
| − | <pre>GET [base]/Observation/$lastn?max=5&category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | {{Collapse top|Get latest lab result of any type for patient with BSN 111222333}}
| |
| − | <pre>GET [base]/Observation/$lastn?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>
| |
| − | {{Collapse bottom}}
| |
| − | | |
| − | <!--{{Collapse top|Get lab result of any type with business identifier 999888777}}
| |
| − | <pre>
| |
| − | GET [base]/Observation?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&dentifier=999888777</pre>
| |
| − | {{Collapse bottom}}
| |
| − | -->
| |
| − | | |
| − | '''Query parameters overview'''
| |
| − | | |
| − | Servers SHALL at minimum support all stated parameters and modifiers, and MAY support additional parameters and modifiers. Clients SHALL support required parameters, and MAY support optional parameters.
| |
| − | * {{fhir|category}} - token - 1..1 required - fixed value ''<nowiki>http://terminology.hl7.org/CodeSystem/observation-category|laboratory</nowiki>''
| |
| − | * {{fhir|patient}} - token - 0..1 conditional - required if not solved using an alternative method like an authorization token
| |
| − | ** Modifier {{fhir|:identifier}} - 0..1 optional - required when searching by identifier
| |
| − | * {{fhir|code}} - token - 0..1 optional
| |
| − | * {{fhir|identifier}} - token - 0..1 optional - required when searching by unique identifier assigned to the observation
| |
| − | * {{fhir|date}} - date - 0..1 optional
| |
| − | ** Prefix {{fhir|eq}} - 0..1 optional - required when searching for results with {{fhir|.effective}} on exact date
| |
| − | ** Prefix {{fhir|lt}} - 0..1 optional - required when searching for results with {{fhir|.effective}} before date
| |
| − | ** Prefix {{fhir|le}} - 0..1 optional - required when searching for results with {{fhir|.effective}} on or before date
| |
| − | ** Prefix {{fhir|gt}} - 0..1 optional - required when searching for results with {{fhir|.effective}} after date
| |
| − | ** Prefix {{fhir|ge}} - 0..1 optional - required when searching for results with {{fhir|.effective}} on or after date
| |
| − | * {{fhir|_count}} - positiveInt - 0..1 optional
| |
| − | * {{fhir|_include}} - reference - 0..* optional - useful for request to include secondary related resources, e.g.:<br/>{{fhir|<nowiki>_include=Observation:patient,Observation:performer,Observation:has-member,Observation:specimen</nowiki>}}
| |
| − | ** Note that servers MAY, depending on their read capabilities, choose to implement inclusion of resources regardless of a client requesting this to satisfy the [[FHIR:V1.0_FHIR_IG_R4|generic requirement]] that references SHALL be resolvable.
| |
| − | | |
| − | '''Operations'''
| |
| − | | |
| − | * [https://www.hl7.org/fhir/r4/observation-operation-lastn.html {{fhir|lastn}}] - shortcut FHIR core operation for getting the latest X results of specified types, or 'any' type
| |
| − | ** Parameter {{fhir|max}} - positiveInt - optional - default is {{fhir|<nowiki>max=1</nowiki>}}
| |
| − | NOTE: Not all parameters listed above need to be used in combination with the {{fhir|$lastn}} parameter.
| |
| − | | |
| − | ======Expected actions======
| |
| − | The XIS/LIS (LAB-LRB) SHALL process the query to retrieve laboratory results.
| |
| − | | |
| − | ====LAB-LRB: response message====
| |
| − | The XIS/LIS (LAB-LRB) returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching information. Refer to the generic [[FHIR:V1.0_FHIR_IG_R4|FHIR IG]] for more information on handling errors and status codes. Not finding a match based on stated parameters does not constitute an error.
| |
| − | | |
| − | =====Trigger events=====
| |
| − | The XIS/LIS (LAB-LRB) completed the processing of the retrieve laboratory results request message.
| |
| − | | |
| − | =====Message semantics=====
| |
| − | The XIS/LIS (LAB-LRB) SHALL process the request and, unless an error is found, respond with a Bundle resource of type ''searchset''. Each Observation matching the request SHALL be marked with {{fhir|.entry.search.mode}}={{term|match}}. Each otherwise included resource SHALL be marked with {{fhir|.entry.search.mode}}={{term|include}}. If the searchset bundle contains less '''matching''' resources than the actual total set, then:
| |
| − | * the {{fhir|Bundle.link}} that holds the self link, SHOULD include the {{fhir|_count}} parameter to inform the client of what max was applied
| |
| − | * an OperationOutcome SHOULD be included marked with {{fhir|.entry.search.mode}}={{term|outcome}}.
| |
| − | | |
| − | The resources in the response Bundle SHALL be a valid instance of their stated [[#FHIR_Profile_Package|profile]]. All resources SHALL include their related profile canonical URL in the {{fhir|.meta.profile}} element in order to show compliance. The exception is the OperationOutcome resource for which there is no profile in this specification.
| |
| − | | |
| − | '''Example searchset Bundle'''
| |
| | | | |
| − | {{Collapse top|XML contents for searchset Bundle}}
| + | |- style="color: white; background-color: #e7844b;" |
| − | <syntaxhighlight lang="xml">
| + | ! Transaction group || Transaction || Actor || System role code || FHIR CapabilityStatement |
| − | <Bundle xmlns="http://hl7.org/fhir">
| |
| − | <id value="1"/>
| |
| − | <type value="searchset"/>
| |
| − | <total value="3"/>
| |
| − | <link>
| |
| − | <relation value="self"/>
| |
| − | <url value="http://example.org/fhir?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory&patient:identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&code=http://loinc.org|14683-7"/>
| |
| − | </link>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Observation/1"/>
| |
| − | <resource>
| |
| − | <Observation>
| |
| − | <!-- -->
| |
| − | </Observation>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="match"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Observation/2"/>
| |
| − | <resource>
| |
| − | <Observation>
| |
| − | <!-- -->
| |
| − | </Observation>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="match"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Observation/3"/>
| |
| − | <resource>
| |
| − | <resource>
| |
| − | <Observation>
| |
| − | <!-- -->
| |
| − | </Observation>
| |
| − | </resource>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="match"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Specimen/1"/>
| |
| − | <resource>
| |
| − | <Specimen>
| |
| − | <!-- -->
| |
| − | </Specimen>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="include"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Patient/1"/>
| |
| − | <resource>
| |
| − | <Patient>
| |
| − | <!-- -->
| |
| − | </Patient>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="include"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | <entry>
| |
| − | <fullUrl value="https://example.org/fhir/Organization/1"/>
| |
| − | <resource>
| |
| − | <Organization>
| |
| − | <!-- -->
| |
| − | </Organization>
| |
| − | </resource>
| |
| − | <search>
| |
| − | <mode value="include"/>
| |
| − | </search>
| |
| − | </entry>
| |
| − | </Bundle>
| |
| − | </syntaxhighlight>
| |
| − | {{Collapse bottom}}
| |
| | | | |
| − | '''Example OperationOutcome'''
| + | |- style="background-color: #fcf0e9;" |
| | + | | rowspan="2" | Send laboratory results (PUSH) |
| | + | | Send laboratory results || Client || LAB-LRS || rowspan="2" |{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/Lab2Healthcare-Results-SendReceive|nictiz.fhir.nl.r4.labexchange|pkgVersion=3.0.0-beta.4|title=Lab2Healthcare_Results_SendReceive}} |
| | | | |
| − | {{Collapse top|XML contents for OperationOutcome}}
| + | |- style="background-color: #fcf0e9;" |
| − | <syntaxhighlight lang="xml">
| + | | Receive laboratory results || Server || LAB-LRO |
| − | <OperationOutcome xmlns="http://hl7.org/fhir">
| |
| − | <id value="size-exceeded-1"/>
| |
| − | <issue>
| |
| − | <severity value="warning"/>
| |
| − | <code value="too-costly"/>
| |
| − | <details>
| |
| − | <text value="Resultaat was 3000, wat meer is dan het maximum van 1000"/>
| |
| − | </details>
| |
| − | </issue>
| |
| − | </OperationOutcome>
| |
| − | </syntaxhighlight>
| |
| − | {{Collapse bottom}}
| |
| | | | |
| − | =====LAB-LRR: Expected actions=====
| + | |+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Abbreviations: LAB = Laboratorium, LRS = Laboratoriumresultaat sturend (systeem), LRO = Laboratoriumresultaat ontvangend (systeem).'' |
| − | The XIS/LIS (LAB-LRR) SHALL process the response Bundle in accordance with the intentions of the trigger event that caused the retrieve. Actions may include discrete rendering on screen or in context with other information, triggering alerts on trends, ordering of (other) tests and more.
| |
| − | | |
| − | ==Health professional sends lab results to other health professional==
| |
| − | ===Introduction===
| |
| − | The functional design distinguishes two use cases where lab results may be sent with something else or separate. The process of 'sending' things in FHIR works by means of a [http://hl7.org/fhir/r4/http.html#create RESTful 'create'] action. You could create a single Observation on another system using {{fhir|POST Observation}} and the appropriate Observation in the request body. When you have multiple Observations to create, you could do that for every single Observation, or by means of a Bundle with all resources. This same Bundle approach works for one Observation too.
| |
| − | | |
| − | The added benefit of a Bundle lies in having a solution for all other resources you may want to send, e.g. MedicationRequest, and referenced resources like Patient, PractitionerRole, Practitioner and Organization. Sending the Observation without the resources it references would only work if the receiving server can resolve those. They should then already exist on that server, with references to them or they should be accessible on the source. Without access to the references in the Observation, the target server may not know which patient is involved or what lab this result came from.
| |
| − | | |
| − | ===Actors===
| |
| − | {| class="wikitable" "cellpadding="10"
| |
| − | ! style="text-align:left;"| '''Transaction group'''
| |
| − | ! style="text-align:left;"| '''Transaction'''
| |
| − | ! style="text-align:left;"| '''Actor'''
| |
| − | ! style="text-align:left;"| '''Role'''
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;" rowspan="2"|Send laboratory results (PUSH)
| |
| − | |style="background-color: white;vertical-align:top;"|Send laboratory results
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatSturend Systeem [LAB-LRS]
| |
| − | |style="background-color: white;vertical-align:top;"|Send lab results to the LAB-LRO
| |
| − | |-
| |
| − | |style="background-color: white;vertical-align:top;"|Receive laboratory results
| |
| − | |style="background-color: white;vertical-align:top;"|LaboratoriumresultaatResultaatOntvangend Systeem [LAB-LRO]
| |
| − | |style="background-color: white;vertical-align:top;"|Respond to received lab results from the LAB-LRS
| |
| | |} | | |} |
| − |
| |
| − | ===Invocations===
| |
| − | ====LAB-LRS: request message====
| |
| − | The XIS/LIS (LAB-LRS) sends lab results using the HTTP POST method on the target XIS's (LAB-LRO) base. Note that lab results may or may not be sent in tandem with other resources like MedicationRequest. The same principles apply with or without these other resources. The server can only process the incoming request correctly if it understands what is being sent which includes being able to resolve references.
| |
| − |
| |
| − | =====Trigger Events=====
| |
| − | This message is invoked when the XIS needs to send one or more laboratory results to another XIS.
| |
| − |
| |
| − | =====Message Semantics=====
| |
| − | Because sending laboratory results will most likely consist of multiple Observations, a {{term|transaction}} interaction is used. This allows for creating a set of resources in a single interaction and makes it possible to [[FHIR:V1.0_FHIR_IG_R4#Referring_other_resources_when_sending_information|include referenced secondary resources]] if needed.
| |
| − |
| |
| − | A {{term|transaction}} interaction is performed by an HTTP POST command as shown:
| |
| − |
| |
| − | <pre>POST [base]</pre>
| |
| − |
| |
| − | The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|transaction}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the transaction of what to do for the entry. (Note: {{fhir|.request}} SHALL be present, even for the resources which aren't Observations. See [[FHIR:V1.0_FHIR_IG_R4#Referring_other_resources_when_sending_information|the overarching principles]] for more information.)
| |
| − |
| |
| − | '''Identification'''
| |
| − |
| |
| − | Resources SHALL have a stable identifier in the {{fhir|.identifier}} element for all resources if such an identifier exists in the underlying data. Not all data, like individual results, are currently known to have identifiers in all source systems, but when they exist they are essential and where they do not exist yet they SHOULD be considered. Having stable identification is essential in detection of duplicates and potential clinical decision making issues deriving from duplicates. For more information on dealing with identifiers, see the [[FHIR:V1.0_FHIR_IG_R4#Usage_of_the_.id.2C_.identifier_and_.fullUrl_elements_in_FHIR_instances|general FHIR IG]].
| |
| − |
| |
| − | '''Read more'''
| |
| − |
| |
| − | * [http://hl7.org/fhir/r4/http.html#transaction transaction]
| |
| − | * [http://hl7.org/fhir/r4/http.html#create create]
| |
| − | * [http://hl7.org/fhir/r4/http.html#ops HTTP Prefer header]
| |
| − |
| |
| − | The laboratory result data sent to the XIS SHALL conform to the matching profile(s) listed in the [[#FHIR_Profile_Package|profile]] table. That table contains profiles that represent applicable zibs for laboratory result information exchange.
| |
| − |
| |
| − | ======Expected Actions======
| |
| − | On receipt of the submission, the XIS (LAB-LRO) SHALL:
| |
| − |
| |
| − | * process all contained requests successfully or process nothing.
| |
| − | * process creation of or updating all Observation resources.
| |
| − | ** Updating might be in order e.g. when corrections are sent or when previously pending tests have been updated with results.
| |
| − | * match Patient, Practitioner(Role), Organization to pre-existing resources on its server.
| |
| − | ** The server MAY update pre-existing information with the incoming information.
| |
| − | ** The server MAY keep its pre-existing matching resources as-is.
| |
| − | ** The server SHALL create new resources if no matching resource is found (unknown patient, new physician in otherwise known organization, etc.).
| |
| − | * decide if any available Specimen and/or Device resources are relevant.
| |
| − | ** If the server decides to ignore Specimen or Device information, it SHALL not keep the references to them.
| |
| − | * respond using HTTP 200 and a Bundle with detail in case of success. See [[FHIR:V1.0_FHIR_IG_R4#Handling_errors|FHIR IG Handling Errors]] for response options in case of errors.
| |
| − | ** Note that the response Bundle with type {{term|transaction-response}} SHALL be specific about how the server handled the request Bundle.
| |
| − |
| |
| − | ====LAB-LRO: response message====
| |
| − | The XIS (LAB-LRO) returns an HTTP Status code appropriate to the processing outcome and returns a Bundle with {{fhir|Bundle.type}}={{term|batch-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.
| |
| − |
| |
| − | =====Trigger Events=====
| |
| − | The XIS (LAB-LRO) completed processing of the send laboratory results message.
| |
| − |
| |
| − | =====Message Semantics=====
| |
| − | The XIS (LAB-LRO) SHALL return a Bundle with {{fhir|Bundle.type}}={{term|batch-response}} that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.
| |
| − |
| |
| − | A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and {{fhir|ETag}} header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the {{fhir|Prefer}} header sent by the LAB-LRS.
| |
| − |
| |
| − | Read more:
| |
| − | * [http://hl7.org/fhir/r4/http.html#create create]
| |
| − | * [http://hl7.org/fhir/r4/http.html#batch batch]
| |
| − | * [http://hl7.org/fhir/r4/http.html#ops HTTP Prefer header]
| |
| − | * [http://hl7.org/fhir/r4/http.html#versioning HTTP ETag header]
| |
| − |
| |
| − | =====Expected Actions=====
| |
| − | The XIS/LIS (LAB-LRS) processes the results according to application-defined rules. The most basic of those rules would include marking the transaction as sent/processed successfully or flag a need for action like resending or contacting the LAB-LRO.
| |
| − |
| |
| − | =====Handling Errors=====
| |
| − | The XIS (LAB-LRO) may be unable to accept a Bundle due to errors or because of technical or business rules. Refer to the [[FHIR:V1.0_FHIR_IG_R4#Handling_errors#Handling_errors|Handling Errors section]] in the FHIR IG for more information.
| |
| − |
| |
| − | ==Health professional reports result leading into a notification "new lab results" for subscribed healthcare professional(s)==
| |
| − | ''This use case will be added in a future release.''
| |
| − |
| |
| − | =Release Notes=
| |
| − | Please note that we have gained new insights based on the developments in HL7 Europe and the HL7 WGM. The necessary changes based on this feedback will be addressed and released in the next release.
| |
