Stream: norway
Topic: Koloskopijournal
Jon Aarbakke (Jul 06 2020 at 15:47):
Heisann, Jeg er også noob... men sitter og forsøker å finne FHIR-ressurser som matcher koloskopidata som skal rapporteres inn til Tarmscreeningprogrammet som Kreftregisteret administrerer. Akkurat nå sitter jeg og klør meg i hodet over dokumentasjonen av FHIR. Hvis man feks ser på Procedure, så har den en attributt som heter "usedCode". Beskrivelsen er syltynn. Er dette typisk FHIR, hadde jeg nær sagt? Vel, vi må kode proceduren vår med NCSP-koder (minst) , og finner sikkert en måte å gjøre det på. Men om dere har noen tips om hvordan man bør navigere i FHIR-jungelen, så fyr løs. Beskrivelsen av BackboneElement er litt i samme gata... man blir ikke umiddelbart grepet av AHA-følelsen!
Kenneth Myhra (Jul 07 2020 at 15:12):
Hei @Jon Aarbakke, det er nok ikke fullt så enkelt å navigere de forskjellige ressursene og dokumentasjonen kan være tung å lese. Selv har jeg måtte lese tekstene på ressursene opptil flere ganger før jeg "catcher" essensen. Tidvis, etter å ha gjort ett forsøk på å skape meg en formening om brukskontekst for ressursen, har det vært nødvendig å konsultere i #implementers eller en av de andre relevante strømmene.
usedCode og usedReferences synes jeg var ganske greie å forstå, men det var kanskje ikke heller spørsmålet ditt. Jeg ser at usedCode bruker ett kodeverk som eksempel (Example) og dermed kan du benytte NCSP-kodene på dette attributtet. Det krever at du har kjennskap til profilering av FHIR-ressurser.
BackboneElement skal du ikke ha behov for i denne konteksten. BackboneElement kan brukes dersom du lager en helt ny ressurs. Et eksempel på bruk av BackboneElement er det komplekse attributtet Procedure.focalDevice. Siden det ikke eksisterer en datatype som passer attributtet focalDevice har man laget en "custom"/komplekst element ved hjelp av BackboneElement
Jon Aarbakke (Jul 08 2020 at 08:09):
Takk @Kenneth Myhra for hyggelig svar. Jeg tenker at jeg må innstille meg på ikke å komme til dekket bord her :-)
Jeg funderer på å lage en kort beskrivelse av hva vi ønsker å oppnå i dokuments form ; dersom jeg gjør det kan jeg sikkert finne en måte å dele det med communitiet på? Google docs, kanskje. (antar det ikke finnes noen "FHIR 101" der ute?)
Jon Aarbakke (Jul 08 2020 at 08:40):
PS - jeg vet ikke hvordan man navigerer "implementers"; kan noen hjelpe meg å finne ut om det finnes en FHIR-dings for koloskopi/endoskopirapporter i verden "out there"?
René Spronk (Jul 08 2020 at 09:01):
Try https://chat.fhir.org/#narrow/stream/179166-implementers/search/colonoscopy ..
Jon Aarbakke (Jul 08 2020 at 09:25):
@René Spronk thanks a lot for that! The search did not return very much. But I shall not be defeated. Stay tuned...
Øyvind Aassve (Jul 08 2020 at 09:57):
Hei Jon, vi har ikke kommet ordentlig i gang her, men du kan jo legge ut lit info om aktiviteten på Aktiviteter i Norge https://github.com/HL7Norway/best-practice, og lenke til den i diskusjoner.
Jon Aarbakke (Jul 09 2020 at 10:24):
Jeg har laget et offentlig dokument i Google som oppsummerer (håper jeg) problemstillingen. Alle med lenken kan redigere dokumentet.. Det er på engelsk. Hvor bør jeg evt legge det ut "internasjonalt"? https://docs.google.com/document/d/1FUY500hEiQsw8hiyjNShDtVY7lbPZrzygP3djl7ZPsY/edit?usp=sharing
Jon Aarbakke (Jul 09 2020 at 20:39):
@René Spronk take a look at my document, linked above? :-)
Kenneth Myhra (Jul 10 2020 at 06:17):
@Jon Aarbakke
Ser ut til at du har god kontroll på hvilke ressurser du trenger, men at det er selve oppbyggningen av ett komplett dokument og utvekslingen av dette du har spørsmål rundt.
Du skriver at en ressursreferanse ikke er godt nok. Klarer du deg med en referanse som inneholder en nasjonal identifikator (fnr) + visningsnavn ved å bruke Reference.Identifier?
Kanskje FHIR Documents er rette veien å gå i denne konteksten. Se FHIR Documents for dokumentasjon på hvordan bygge ett FHIR Document og utveksle dette med en tredjepart via REST. Acknowledgement som du referer til i dokumentet vil da være en HTTP respons av type 200/201.
Dersom du mener FHIR Documents/Documents exchange ikke passer ditt scenario så har du meldingsutveksling, men det virker på meg som FHIR Documents er en farbar vei dersom du kan få opp et REST API.
Jon Aarbakke (Jul 10 2020 at 07:09):
Tusen takk @Kenneth Myhra ; dette hjelper bra. Jeg må sjekke ut Document-ressursen. Det jeg mener med "referanser ikke godt nok" er kanskje upresist formulert. Det jeg tenker er at mottaker skal slippe å gjøre et kall tilbake til avsender for å få tak i Patient/Practitioner-ressursen. Det er forresten lite info om disse som trengs: for pasient er det fnr, for practitioner HPR-nummer, men jeg tenker at det er vel penere å sende en ressurs med noen minimumsattributter enn kun en identifier. Anyway - leser meg opp på Document!
Kenneth Myhra (Jul 10 2020 at 07:26):
Ved å bruke Reference.identifier og angi fødselsnummer her så vil avsender slippe å gjøre kall tilbake til avsender, penere er relativt.. Mitt syn er at jo færre ressurser man sender og jo mer man kan basere seg på unike nasjonale identifikatorer, særlig er dette relevant i kontekst av personer, jo bedre er det, men det er en lengre diskusjon som jeg ikke ønsker ta her..
FHIR Documents er en Bundle av type 'document' med en Composition som første ressurs. Fra Composition så referer du til de andre ressursene du har inkludert i Bundle, men ja les deg opp.
René Spronk (Jul 10 2020 at 08:05):
Any Bundle would work, remember that the whole point of documents is a) persistence, and b) human readability. I haven't heard anything about these two things in the requirements. As such a bundle of type batch would work as well, or collection if you assume the receiver will persist the bundle. @Jon Aarbakke I've looked at the document - some details you point out on procedures could be extensions, or captured as observations on the procedure resource. I'm aware of the Dutch national colonoscopy screening program (although I haven't been involved myself) - they've mapped their requirements to CDA [this is a couple of years ago], and not to FHIR. I'd encourage you to take your document to the #implementers channel, to see whether there are others working on similar things.
Kenneth Myhra (Jul 10 2020 at 08:41):
Yes agree that any Bundle would work. But then it is as I understand it from the documentation it is no longer Document exchange/FHIR Document
From http://hl7.org/fhir/documents.html#content
All documents have the same structure: a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource, that provide supporting evidence for the document.
Maybe I put too much into this part of Jon's document
The entire set of information should be sent in one operation, as a self-contained, complete document.
René Spronk (Jul 10 2020 at 09:46):
He'll need to define quite what he means by using the word "document". That may very well not be in the strict sense of the meaning as defined by FHIR.
Øyvind Aassve (Jul 10 2020 at 14:33):
@René Spronk - what would you say would be a sufficient need of persistence to justify the use of Document for this report? We have been discussing this in a couple of other cases as well here in Norway. If this Coloscopi-report is signed by a clinician that would typical require use of Document instead of Bundle because you would like to preserve the integrity of the report?
Øyvind Aassve (Jul 10 2020 at 14:34):
@René Spronk - an additional question out of curiosity. Have you implemented some FHIR Documents in the Netherlands or is the main track still CDA?
René Spronk (Jul 10 2020 at 14:49):
The future direction is firmly FHIR, there actually have been very few CDA based projects. Documents = persistence, human readability, attested textual content. If you only want persistence, go for a bundle of type collection. Which could still contain a Composition, if you want to.
Øyvind Aassve (Jul 10 2020 at 15:03):
"A structured report is first created in an EHR that supports structured reporting. That report is signed." - would this not qualify as "attested texutal content"? Or can you say this is a difference in that it rather contains attested structured content?
Øyvind Aassve (Jul 15 2020 at 11:24):
@René Spronk
René Spronk (Jul 15 2020 at 11:31):
Signed doesn't mean anything, because all bundles or resources could be signed. CDA defines these document characteristics:
Persistence – A document continues to exist in an unaltered state
Stewardship – A document is maintained by an organization entrusted with its care.
Potential for authentication - A document is an assemblage of information that is intended to be legally authenticated.
Context - A document establishes the default context for its contents.
Wholeness - Authentication of a document applies to the whole and does not apply to portions of the document without the full context of the document.
Human readability – A document is human readable.
Øyvind Aassve (Jul 15 2020 at 11:41):
Thanks Rene, is the question then whether or not the Colonyscope report adheres to these characteristics? Is this information the project will need to answer, for now we do not have information on what the planned business rules for handling this set of information will be?
Øyvind Aassve (Jul 15 2020 at 15:19):
@René Spronk
René Spronk (Jul 15 2020 at 15:27):
If it has all of those characteristics, then the best match would be a FHIR document. Human readability doesn't seem to be relevant in your use-case, which is a SHALL in a document. So that'd mean a collection would be closer to what you need than a document.
Øyvind Aassve (Jul 16 2020 at 07:12):
@René Spronk - do the same characteritics (as a CDA document) also apply to a FHIR document? The specification does not mention these requirements for use specifically. "The composition resource is the foundation of the clinical document. It:
- provides identity and its purpose, and sets the context of the document
- carries key information such as the subject and author, and who attests to the document
- divides the document up into a series of sections, each with their own narrative"
Grahame Grieve (Jul 16 2020 at 07:32):
it says them under documents rather than against Composition which has wider usage than just documents
Øyvind Aassve (Jul 16 2020 at 09:35):
@Grahame Grieve - In the 4.th paragraph under FHIR Documents it says: "FHIR documents may be 'clinical' (focused on patient healthcare information) but may also serve non-clinical purposes (e.g. FHIR Implementation guides, practice guidelines, patient handouts, etc.)" which makes it seem pretty broad. To me there seems there might be a difference between document requirements described under FHIR document and Compostion and the pretty strict characteristics for a document desribed for CDA > persistence, stewardship, context, human readbility, wholeness, potential for autentication. With regards to this specific use-case - do you see any issues with choosing Bundle.type=document with use of Composition for a colonoscopy-report even in the case where possibly not all the CDA-requirements for a document are checked off?
René Spronk (Jul 16 2020 at 14:32):
For all intends and purposes, FHIR Documents are the next version of CDA (without the C, given that the scope is wider than just clinical docs in FHIR). They may have reworded the principles, but those effectively remain the same.
Grahame Grieve (Jul 16 2020 at 21:11):
well... you should check out SDA vs CDA, where the breadth comes from.
Grahame Grieve (Jul 16 2020 at 21:12):
actually, I thought that page quoted from the CDA wording
Grahame Grieve (Jul 16 2020 at 21:12):
but apparently not.
Grahame Grieve (Jul 16 2020 at 21:13):
@Rick Geimer can you provide an opinion?
Jon Aarbakke (Aug 10 2020 at 13:25):
Thanks for running this discussion in my absence. To try to narrow it down, @René Spronk , if you were to create a discharge document (epikrise) in FHIR, would that be a Document? As for human readable - that is not a requirement in our case. I imagine JSON is not included in "human readable" :-)
Essentially, there is master source of information in the EHR and a copy is sent to a recipient. If/when a change occurs in the master, a new version is sent to the recipient.
So we are pushing information.
I sometimes feel FHIR is more pull-oriented (read-only, read-and-display), and prefers small chunks of information. But like I said, I am a noob.
René Spronk (Aug 11 2020 at 06:11):
So if I were to translate your description to: after the discharge of the patient, you push a bucket-full of relevant [structured, not textual] data related to the encounter to some other party, to act as a summary of things that happened during the encounter. This data may be used by the receiver if and when they deal with the patient themselves.
The key question to ask is then: do both the sender as well as the receiver persist/archive the overall 'bucket of data' or do they only persist the data itself, as individual FHIR resources ?
Jon Aarbakke (Aug 11 2020 at 10:31):
Thanks for replying! The data is used for research in this case - the patient is never seen. The receiver will in this case keep the received "bucket" for future reference, but also extract, transform and aggregate the received data. FHIR is only really used for transport. BR
René Spronk (Aug 11 2020 at 12:31):
So, a collection, http://build.fhir.org/codesystem-bundle-type.html#bundle-type-collection ? Only alternative would be batch (where there is no requirement for persistence).
Note that FHIR Messaging (http://build.fhir.org/messaging.html) or a custom operation might also work given the use case, but that wasn't your question.
Jon Aarbakke (Aug 12 2020 at 08:55):
Thanks, I am trying to get my head around this, and in particular, find the relevant documentation on Collections!
René Spronk (Aug 12 2020 at 09:50):
Good luck with your project. You may have to ask around, I don't think a lot of projects have been using the Collection bundle.
Jon Aarbakke (Jan 28 2021 at 12:41):
Our project is going ahead and we are collaborating with Firely on defining the colonoscopy report for the Cancer Registry. The main issue right now is the overall structure. Current assumption: A Bundle of type Collection. We have discussed Document, but our report is not for human consumption. I hasten to add that the data included do not cover all clinical aspects; this is data destined for quality monitoring of the national colon screening programme, starting late 2021.
The report that the clinician files in the EPR will contain additional attributes, and will have a broader usage area. The screening programme never carries out colonoscopies to scout for Crohns, or as follow up to appendicitis etc.
So, the issue I need to settle first is the overall structure. We shall use resources like Practitioner, Procedure, DiagnosticReport, but shall have to use QuestionnaireResponse in places.
As for value sets, we are working on that, too. ehelse/Linn Brandt is handling this.
Input appreciated! @Espen Stranger Seland @Linn Brandt @Øyvind Aassve @Marten Smits
Espen Stranger Seland (Jan 28 2021 at 12:52):
Do you have any UML og Logical Models to share with us?
Thomas Tveit Rosenlund (Jan 28 2021 at 14:21):
Have you considered or studied the daVinci project? They are trying to solve some similar use-cases (quality measures). Their implementation guide is currently on version 2.0.0 might be worth a look?
http://hl7.org/fhir/us/davinci-deqm/
@Jon Aarbakke
Øyvind Aassve (Jan 28 2021 at 15:14):
Sounds good. Does this mean that Questionnaire is not the root of the clinical information any more, but rather DiagnosticReport? Did you find any relevant structures to reuse in the mCode/ CodeX IGs? @Jon Aarbakke @Marten Smits
Jon Aarbakke (Jan 29 2021 at 11:33):
You can all keep an eye on our efforts here: https://simplifier.net/NorwegianColonoscopyReport/example-1/~overview
Marten Smits (Feb 01 2021 at 09:40):
@Øyvind Aassve The Design is still to use QuestionnaireResponse for some cases. It is one of multiple resources (including DiagnosticReport and Procedure) we use. All contained in a single Bundle (of type "collection).
Marten Smits (Feb 01 2021 at 09:41):
The profiles are still a work in progress, but if there are any questions, please feel free to reach out!
Øyvind Aassve (Feb 01 2021 at 11:30):
@Marten Smits - sounds good. We could arrange a presentation for HL7 Norway TSC when you are ready to present. Would that be ok? If so, when could you be ready?
Øyvind Aassve (Feb 01 2021 at 11:36):
@Jon Aarbakke
Jon Aarbakke (Feb 01 2021 at 14:47):
@Thomas Tveit Rosenlund daVinci seems to be about aggregated data? Not individual screening reports?
Øyvind Aassve (Feb 01 2021 at 16:28):
DaVinci i a broad program, but main focus is on the payers. Might be more financially oriented than this work .... @Jon Aarbakke @Thomas Tveit Rosenlund
Thomas Tveit Rosenlund (Feb 01 2021 at 17:19):
@Jon Aarbakke You are probably right. The reports can be generated for individual patients, but the focus is on aggregation of the underlying individual data. However, the bundle can (and examples show how) to include the observations evaluated as part of the MeasureReport. http://hl7.org/fhir/us/davinci-deqm/col.html
Last updated: Apr 12 2022 at 19:14 UTC
