Stream: implementers
Topic: Operation made by practitioner
Lauri Karppinen (Feb 06 2019 at 08:00):
I'm working on storing operator, organization and operation. Operator information should easily go to practitioner resource. Organization to organization resource. These both will be referenced from study observation "performer" key. Study observation resource groups these together. My question is what would be the best way to present the operation made. There is 3 options what practitioner can make: measurement, update for measurements or calibration for device.
Lloyd McKenzie (Feb 06 2019 at 14:56):
Can you explain what "update for measurements" means? (Also, @Eric Haas )
Eric Haas (Feb 06 2019 at 18:39):
can you explain what you mean by 'study observation' too?
Lauri Karppinen (Feb 07 2019 at 06:39):
@Eric Haas It's observation resource which contains information that it's a spirometry stydy. It has references to chain(tree stucture) of other resources and observations(protocol, phase, measurement mode, breath, flow&variable), device, binary, height, weight, BMI etc... and "groups" them together. @Lloyd McKenzie If practitioner makes new study to patient then he/she makes measurement. If this practitioner goes back to study and updates some some information to existing study then it's update.
Lloyd McKenzie (Feb 07 2019 at 07:04):
Second or third measurements would be treated as additional Observations, not as updates. You can group them under a "grouper" observation linking them as members. The timestamps would tell you the order they were done in. Differentiating a measurement done for calibration purposes could be differentiated using the workflow-reasonCode extension I suppose
Lauri Karppinen (Feb 07 2019 at 07:07):
@Lloyd McKenzie I edited my message I wrote wrong in the original. So it's a measurement every time measurement is done. Update when practitioner goes back to study and add's or modifies some information to study.
Lauri Karppinen (Feb 07 2019 at 07:21):
Actually there is 4 fields I need to store in relation to the operation: operation(measurement/update), operationID, operationTime, and username of practitioner who made that operation. (real name of practitioner goes to practitioner resource) These are the "fields" from our application what I'm struggling to find the place to store them.
Lloyd McKenzie (Feb 07 2019 at 15:38):
That sounds like Provenance. That lets you capture what action/operation happened on the record, who did it and when. Username would be an extension.
John Moehrke (Feb 07 2019 at 15:42):
if you don't have a Practitioner resource to put into Provenance.agent.who.reference; then put the username into Provenance.agent.who.identifier.
Eric Haas (Feb 07 2019 at 17:24):
I admit I don't understand your use case but I don't think that Observation should be used as a top level grouping resource when this sounds more like a report to me aka a DiagnosticReport or even a Composition.
Lauri Karppinen (Feb 08 2019 at 10:24):
Thanks a lot for the answers! :)
@Eric Haas Yes there is actually observation in top of my structure. I might have to change it to DiagnosticReport if using observation is not right way to group everything. This has been a big project to fit all data from our software to FHIR. I have tried to make it so it would follow FHIR specifications. But I must admit that there must be some mistakes along the way since I started this whole project with 0 knowledge of FHIR. There has been fairly much of guessing where to put this and that. I have tested my resources as a bundle to http://hapi.fhir.org/baseDstu3/ along the way.
Thanks @Lloyd McKenzie Provenance seems just what I was looking for. I will use CREATE for "measurement" and UPDATE for update. Id can be used as id of resource and recorded as time of operation.
@John Moehrke now I have practitioner, provenance and organization to work with. I'm planning that organization and practitoner could be referenced from "performer" of observation. And practitioner from agent.whoReference of Provenance. I could actually use identifier of practitioner to present username? What would be identifier system to use if I put username as value of practitioner.identifier?
John Moehrke (Feb 08 2019 at 15:57):
typically usernames are much like identifiers, they have a value and a domain... For example: JohnMoehrke@gmail.com... the value is JohnMoehrke, the domain (system) is gmail.com.
Lauri Karppinen (Feb 11 2019 at 06:58):
@John Moehrke What if there is only a username and password? Password is of course not stored. It's either internal user. So you decide your username whereby You log in to our software. So for me it could be laurikarp12 for example. Or it can be windows group based or windows user based username. For example: GRP\GROUP-USERS or GRP\LAURI. I found this: https://www.hl7.org/fhir/valueset-identifier-type.html. Could I use this as a type of identifier. Code ACSN Accession ID sounds something that I'm trying to store? I've been trying to find some examples for this but with no luck. Any help would be much appreciated! :)
Lauri Karppinen (Feb 11 2019 at 07:45):
Could this be the way to present this username? Example:
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "ACSN"
}
]
},
"value": "karpla"
}
],
So this identifier would go to practitioner resource.
Last updated: Apr 12 2022 at 19:14 UTC
