|
|
| Line 32: |
Line 32: |
| | ::* supporting info: goal is that only relevant information is sent in the referral | | ::* supporting info: goal is that only relevant information is sent in the referral |
| | | | |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | ::* It is felt we shall have possibilities in the technical profile to provide for very detailed information when it is defined what the details entail. e.g. a very detailed valueset of codes is a big aid for semantic interoperability but the absence should not block us from working already towards publication of a technical profile.
| |
| − | ::::* The GP input level is indeed confirmed to be on the detail level as in the examples presented by Karen in a previous WG. However, if a GP (or of course any other prescriber) has information on a more detailed level, the standards should provide for possibilities to include them. A typical example would be detailed information about a pacemaker as the presence of a pacemaker is very relevant. If the prescriber has detailed information on that pacemaker (e.g. the type), the standard should provide to include it.
| |
| − | ::::* The model should provide to include questionnaire responses. Still to be decided when and if we will be able to provide a standard questionnaire.
| |
| − | ::::::* To have a questionnaire would be an added value as it can also contain many non-clinical information. The questionnaire that needs to be answered might exist as Questionnaire resource outside the profile. As such, it could be updated on the fly - this might have an impact on automatization but will provide flexibility if we say e.g. the GP software shall get the Questionnaire at a certain defined endpoint.
| |
| − | ::::::* Such a questionnaire should behave however with caution to not overburden the load for the prescriber and the right questions shall be asked in the right context.
| |
| − | ::::::* Technically, this can be a very pragmatic way to roll out extra questions immediately. (e.g. pandemic related emergency questions)
| |
| − | ::::::* Use of questionnaire will be further discussed in this (or a specialized) WG.
| |
| − | ::* Kidney function is also again confirmed as always very relevant information. This is also a good example where it would be relevant to provide more information.
| |
| − | ::* In general, the model shall always provide for means to include more detailed relevant information when available with the prescriber. It shall also be mentioned it is indeed expected the prescriber provides details on relevant information if the prescriber has those details. (Cfr. pacemaker case supra)
| |
| − |
| |
| − | * The datamodel is reviewed
| |
| − | ::* Building on the minutes supra: in the data model this is expressed as annotation (purely text) or code (structured information but no further details) or reference to something (possibility to provide full details on something)
| |
| − | ::* References to previous imagingStudy: only when relevant for this prescription, not meant as exhaustive overview of previous imaging studies.
| |
| − | ::* Is it needed to provide free text ('Annotation') input for contraIndication and proposedInvestigation?
| |
| − | ::::* To further investigate
| |
| − | ::* Previous laboratory results can be expressed as 'Observation' (they should also be available under contraIndication)
| |
| − | ::* soberExceptMedication does not need to be a seperate element in the model
| |
| − | ::* It should always be clear when extra information is provided in the order it concerns information (or references to information) that is relevant in this order.
| |
| − | ::::* Being relevant is typically something that cannot be enforced technically. Guidance like that should however be provided somewhere in the profile (via extra explanations in the elements and/or a guidance page in a guide)
| |
| − | ::* How to deal with absence of information? Specifically for contraIndication, it would be interesting to have a clear indication why information is not present.
| |
| − | ::::* Using a minimal cardinality of 1 we could enforce behavior using some of the codes in the HL7 nullFlavor set. (i.e. we can define that some codes of https://www.hl7.org/fhir/r4/v3/NullFlavor/cs.html shall be used)
| |
| − | ::::* Typically in this prescription, the prescriber would mark that it was asked/investigated but according to the best knowledge of the prescriber there are no known.
| |
| − | ::::* In the same context, a suspected pregnancy is relevant to signal.
| |
| − | ::* How about certain more detailed rules? (for instance: an echo might imply certain other elements or might imply certain other element are not relevant)
| |
| − | ::::* Best strategy here is to make specialized profiles inheriting from a generic diagnostic imaging profile. (First goal can be the generic diagnostic imaging profile, in a later phase, more specialized profiles can still be defined that are more strict)
| |
| − | ::::* Specifically for contra indication there are added benefits to provide specialized profiles. Too many contra indications may be confusing. Pregancy for example is important to signal as contra indication for CT. If the radiologists in that case decides to do the CT it is clearly the radiologist's responsibility. Kidney insufficiency and diabetics in combination with MRI and CT have different impacts. Diabetics is for example also very important for PET CT. With specialized profiles we can limit or mandate certain informations.
| |
| − |
| |
| − | * An updated datamodel and technical profile will be prepared for next WG to see if we can move towards a finalization of the generic imaging profile. The group feels it could be interesting to get invited to for example the Belgian organization for radiology and/or BELMIP to present our findings.
| |
| − | ::* To follow up within the WG how we proceed here.
| |
| | | | |
| | ''' Date Next Meeting : March 18 at 4PM''' | | ''' Date Next Meeting : March 18 at 4PM''' |
