Stream: committers
Topic: Modelling a Master File (Pharmaceutical)
Rik Smithies (Jul 19 2018 at 21:36):
This is conceptually a document, but typically you just have a code/id, and a type, and a custodian, including a physical location. So I thought DocumentReference, yet that has mandatory content - though the content is an "attachment" so it can be URL rather than actual bytes. But Master File has neither, so is DocumentReference right? In fact all the fields of attachment are optional so I could just ignore, but doesn't seem right.
Lloyd McKenzie (Jul 19 2018 at 22:24):
Master files aren't implicitly documents. Any "knowledge" resource (profiles, value sets, decision support rules, observation definitions, medication definitions, etc.) will have a custodian and similar metadata. They're not documents - they're specific resources. You could compile a bunch of them into a document if you wanted to.
Rik Smithies (Jul 19 2018 at 23:47):
this isn't Master File as in V2 chapter 8 i.e. a catalogue . This is a specific pharma industry thing, e.g. a PSMF see https://bit.ly/2LxDpr7, or an SMF see https://bit.ly/2uAWIcK
Lloyd McKenzie (Jul 19 2018 at 23:54):
Ah. Well, as defined, I guess it's a "document", though the description of it makes it questionable as a "document" in FHIR terms - continuously updated stuff might be better represented in a different way.
Lloyd McKenzie (Jul 19 2018 at 23:55):
So you need to reference a document by an identifier/name but have no location?
Rik Smithies (Jul 20 2018 at 00:09):
well it has a physical location but no electronic one. Somewhat old school, I know. You are supposed to be able to visit the place and inspect it. It's reference to a document by identifier/code, also with a type (e.g. PSMF or SMF), and with a custodian and physical address. DocumentReference without the electronic content would work...
Lloyd McKenzie (Jul 20 2018 at 00:16):
I guess you could put an extension on DocumentReference.content.attachment and specify the address or something. But that would probably break a lot of systems. It might be cleanest to use a custom extension. Alternatively, we could explore whether there are others who have use-cases to be able to identify the physical location of a document
John Moehrke (Jul 20 2018 at 01:06):
Interesting use-case. I know of a site that uses XDS/XCA (which is FHIR DocumentReference) that simply registers the fact they have documents of various types. Basically indicate they have a Patient resource for each patient they know they have paper documents for. This step is often called (Record Location Service). When they get a query for documentReferences (actually XDS DocumenEntry), they delay the transaction for as long as the can. They want to delay it up to 3 days. During this time they send a runner (human) to go fetch the box of paper documents. That runner then puts the paper through an automated paper scanner. I am not sure if they update the DocumentReference, or if hey just concatenate all the paper into one PDF file. This works on the USA Sequoia networks (CareQuality and eHEX). Mostly the timeout causes major problems. In FHIR we might recommend use of Subscription to make it asynchronous. There is no need to include a location. They might encode for their own purposes their physical location, but it is not exposed to the requesting system.
Rik Smithies (Jul 20 2018 at 15:55):
Some similarities, yes. Would they use DocumentReference.content? What would go there?
Last updated: Apr 12 2022 at 19:14 UTC
