-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encounter service event #40
Conversation
Provide more context to encounter intro with an example. Add encounter example fsh:s.
I can't get it to work. Is there an issue in sushi?
I couldn't get this text to fit nicely in the example. Putting it back to the main intro text. Added some stub paragraphs for other relvant parts, so that its clear that patients in a ward is not the only concern we are trying to adress.
First bite at settling the relationship between Kanta Palvelutapahtuma and encounter.
a867edb
to
ff789ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK for me to pull this in now, but I'd like to discuss the approach in our next meeting.
|
||
* extension contains ServiceEvent named serviceEvent 0..1 | ||
|
||
Extension: ServiceEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have thought palvelutapahtumatunniste to be a specific kind of an Identifier.
Usage: #example | ||
* id = "id-for-visit" | ||
* identifier.use = #usual | ||
* identifier.value = "id-for-visit" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usual
identifier should be
the identifier recommended for display and use in real-world interactions.
I don't think id-for-visit
is such an identifier.
I do think a palvelutapahtumatunniste might be...
Description: "An example of a FI Base encounter where a patient is currently receiving care at a ward." | ||
Usage: #example | ||
* id = "id-for-ward-encounter" | ||
* identifier.use = #usual |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as for the ambulatory example.
|
||
The scope of palvelutapahtuma is [described](https://www.kanta.fi/jarjestelmakehittajat/liite-2-palvelutapahtumien-esimerkkeja) | ||
in Kanta-documentation (in finnish). It's scope is not the same as encounter's. Encounter and | ||
Palvelutapahtuma will overlap as concepts (depending on implementation). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have palvelutapahtuma both capitalized and not.
How about not capitalizing it, but always putting it in italics?
|
||
For example a laboratory information system may have it's own Kanta Medical Records capabilities | ||
and will archive lab results directly to Kanta. It receives encounter id in SMART App Launch | ||
context. Laboratory system can resolve Palvelutapahtuma`s OID identifier by fetching the encounter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong kind of an apostrophe here...
|
||
Encounters can be grouped together to form larger administrative 'periods' by using the `partOf` | ||
element. Vendor implementations vary and it's difficult to pinpoint which level (if any) would | ||
match Palvelutapahtuma. For best interoperability we should *not* assume Palvelutapahtuma corresponds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SHOULD NOT?
First bite at Palvelutapahtuma