JBleuer
commented
1 year ago Committed but not visible due to problem with structure mapping
Closed JBleuer closed 1 year ago
JBleuer
commented
1 year ago Committed but not visible due to problem with structure mapping
JBleuer
commented
1 year ago ETOC#54 (https://github.com/hl7ch/ch-etoc/issues/54) initiated the update of home. See the changes in detail here: https://github.com/hl7ch/ch-orf/commit/56e04809abc77cbb1336531b79897c089e19e4b7#135
pjolo
commented
1 year ago Good for me
The Order & Referral by Form (ORF) implementation guide describes how forms for eReferrals, requests for information (such as diagnostic imaging results, lab results, discharge reports etc.) can be defined, deployed and used in order to achieve a syntactical and semantically consistent cross enterprise information exchange.
The implementation guide supports creation and domain wide deployment of forms for structured and coded information exchange as well as exchange of such forms for referral, orders etc. Because the implementation guide relies heavily on the FHIR resources Questionnaire and QuestionnaireResponse, forms are addressed here as Questionnaires.
This implementation guide uses FHIR defined resources – Composition, Questionnaire, QuestionnaireResponse, Patient, PractitionerRole, Practitioner, Organization, ServiceRequest and Bundle from FHIR R4. For details on HL7 FHIR R4 see http://hl7.org/fhir/r4.
This implementation guide is derived from the implementation guides HL7 Structured Data Capture - STU 3 and CH Core - STU 3.
Download: You can download this implementation guide in NPM format from here.
Volume 1 – Implementation Guide
This implementation guide concerns directional information exchange between institutions such as requests for referral, requests for previous imaging results, requests for second opinions etc. as well as corresponding responses. Such request are often done – or could be done – by means of structured forms. The same may apply for responses or documents coming along in case the response consists of a particular payload (e.g. exam results). However, forms for these purposes are in general proprietary constructs and seldom suitable for further machine processing. Furthermore, such forms are more or less hard coded and concerned systems may not easily be updated for new use cases.
The ORF implementation guide addresses two issues:
Vendors implementing the ORF implementation guide benefit of a high re-use potential. Applications which support the ORF implementation guide may be used for various settings of directional information exchange. The specific needs of a particular use case will be covered by a adequate design of the questionnaire and the value sets being used.
When writing the ORF implementation guide, the authors had the following use case in mind: A human fills in a questionnaire for a particular request and sends this questionnaire to a receiver. There, a human reads the questionnaire with its content. A corresponding response will work in the same way. There is possibly some payload coming with the questionnaire: A request may be accompanied by results of preceding exams (e.g. images, reports); the response may be a diagnostic result.
The primary aim of the ORF implementation guide is to assure a consistent representation of questionnaires – both on the filler and on the receiver site. But there is the need for further machine processing: at filler site in terms of prepopulating attributes with content from other applications (e.g. demographic data of a patient) whereas the receiver may want to have the content of the form ready for further processing in his applications. Obviously the two aims – semantic interoperability and flexibility in the definition of questionnaires – are contradictory. The ORF implementation guide addresses this problem by a mandatory set of generic elements and codes with defined meaning which are part of every questionnaire in the ORF implementation guide. It is up to a SDC Form Designer to create questionnaires with additional use case specific elements.
There has been a discussion whether population of the resources such as Patient, ServiceRequest etc. with the content of the QuestionnaireResponse should be done by the order placer application or rather by the order filler application. The argument for assigning the task to the order placer is a result of the following consideration: the authors of a particular implementation guide may decide to define a questionnaire and its rendering but to leave it open if in a particular implementation the questionnaire is implemented or if the representation towards the user is made (in accordance to the questionnaire definition) by other technical means. In such a case, there would be no QuestionnaireResponse resource in the Bundle because all content is already in concerning resources. In order to handle all FHIR exchange formats equal (as far as sensible), the authors decided to mandate the order placer application with the task.
Applications claiming for conformance with the ORF implementation guide shall:
Vendors of applications with Questionnaire Filler/Questionnaire Receiver actors are strongly recommended to implement interfaces to other applications (such as HIS and PACS) for all data in the generics elements of questionnaires.
Applications designed like this will provide out-of-the-box interconnectivity for generic elements as well as out-of-the-box interoperability for all questionnaires as far it concerns user interfaces at filler and receiver site.
Nothing speaks against interfaces for data in the use case specific part of a particular questionnaire. One has however to keep in mind, that such interfaces are tied to a specific questionnaire. Ownership or other means, which prevent changes of the questionnaire by third parties, are therefore advisable.
The ORF implementation guide deals with transport, workflow and content. It is based on FHIR resources and in particular the FHIR Questionnaire resource. FHIR specifies RESTful web services as a mean for transport. An implementation based on RESTful web services is strongly recommended however not mandatory to comply with the ORF implementation guide. Workflow is addressed by the scope of ORF implementation guide which addresses directional information exchange with request and response. Content is defined by a set of generic given elements and codes and the possibility to extend both as required by the use cases addressed.
New version:
The CH Order & Referral by Form (CH ORF) implementation guide and its derivates describe how forms for eReferrals, requests for information (such as diagnostic imaging results, lab results, discharge reports etc.) can be defined, deployed and used in order to achieve a syntactical and semantically consistent cross enterprise information exchange.
Whereas CH ORF is the "mother"-implementation guide defining attributes and value sets necessary in all sorts of order and referrals (such as patient name, order placer and order filler, insurance data etc.), derivates cover specific use cases thus defining dedicated attributes and value sets needed there. Currently under development are CH eTOC for electronic transition of care, CH RAD Order for imaging services and CH LAB Order for laboratory orders.
All support creation and domain wide deployment of forms for structured and coded information exchange. Because the implementation guide relies heavily on the FHIR resources Questionnaire and QuestionnaireResponse, forms are addressed here as Questionnaires.
All IG derived from CH Orf use FHIR defined resources – Composition, Questionnaire, QuestionnaireResponse, Patient, PractitionerRole, Practitioner, Organization, ServiceRequest and Bundle from FHIR R4. For details on HL7 FHIR R4 see http://hl7.org/fhir/r4.
CH ORF and its derivates are derived from the implementation guides HL7 Structured Data Capture - STU 3 and CH Core - STU 3.
Download: You can download this implementation guide in NPM format from here.
Volume 1 – Implementation Guide
The CH ORF implementation guide addresses three issues:
When writing the CH ORF implementation guide, the authors had the following use case in mind: A human fills in a questionnaire for a particular request and sends this questionnaire to a receiver. There, a human reads the questionnaire with its content. A corresponding response will work in the same way. There is possibly some payload coming with the questionnaire: A request may be accompanied by results of preceding exams (e.g. images, reports); the response may be a diagnostic result. Workflow is therefore not a particular issue because directional information exchange is based on a request and response mechanism.
There may be good reasons to implement user interfaces by other technical means than questionnaires. Therefore CH ORF sets the cardinality for the questionnaire / questionnaireResponse to 0.. thus allowing auhtors of derivates to decide if applications following their IG must implement a questionnaire / questionnaireResponse or not. In any case, the questionnaire will give guidance for sequence and grouping of items in the user interface.
A major challenge is the need for further machine processing: at filler site in terms of prepopulating attributes with content from other applications (e.g. demographic data of a patient) whereas the receiver may want to have the content of the form ready for further processing in his applications. Obviously the two aims – semantic interoperability and flexibility in the definition of questionnaires – are contradictory. CH ORF addresses this problem by defining the mandatory set of generic elements and codes with defined being part of every CH ORF derived IG. Derivates will then only define additional case specific elements.
Vendors implementing the CH ORF implementation guide (or one of its derivates) therefore benefit of a high re-use potential.
There has been a discussion whether population of the resources such as Patient, ServiceRequest etc. with the content of the QuestionnaireResponse should be done by the order placer application or rather by the order filler application. The argument for assigning the task to the order placer is a result of nit making the implementation of a questionnaire / questionnaireResponse mandatory: For the sake of keeping all CH ORF derived exchange formats equal (as far as sensible), the authors decided to mandate the order placer application with the task.
Applications claiming for conformance with an CH ORF derived implementation guide shall:
Vendors of applications with Questionnaire Filler/Questionnaire Receiver actors are strongly recommended to implement interfaces to other applications (such as HIS and PACS) at least for all data in the generics elements of questionnaires.